Strategy Router: manifest × channels → plan

Input: launches/<slug>/manifest.yaml + channels/channels.yaml. Output: launches/<slug>/plan.yaml (machine-readable, schema_version: 1) and launches/<slug>/PLAN.md (human rendering). Same facts in both — PLAN.md is a view.

1. Verdicts — every channel gets one

Walk EVERY channel in channels/channels.yaml, including excluded. One verdict each:

• no-go — the channel doesn't fit this project or this user, and no fixable gap would change that. Always the verdict for mode: excluded (reason = exclusion_reason; LaunchPilot never implements those). Also for: audience mismatch (e.g. LinkedIn for a non-B2B tool), invite-only channels where accounts.* is explicitly false (e.g. Lobste.rs without an account), paid-API channels the user hasn't opted into (X/Twitter), own-community channels when the user has none.
• no-go-by-choice — a no-go that follows from an editorial choice of the project, not a structural fact: the verdict is correct today but reversible if the maintainer changes the project. Type case: SaaSHub/AlternativeTo when alternatives_to is empty because the README chooses to name no competitor. Requires reversible_by: naming the exact project change that would flip it. PLAN.md renders these in their own "Reversible if you change the project" section. Distinguish carefully: user-state limits (no community memberships, no paid API tier, no invite) are plain no-go — they are not choices embedded in the project.
• blocked-by-gap — the channel fits, but a gap_report entry blocks it today. Reference the gap in unblocked_by. If the plan schedules the fix, the channel re-enters the timeline after that task — blocked is a state, not a rejection.
• go — fits and nothing blocks it. If a requirement depends on user-declared state that is still unknown (HN/Reddit/PH account status), the verdict may still be go but MUST carry a preconditions: list; each precondition becomes a D-7 "confirm" task in the timeline.

Every verdict gets a one-line reason grounded in manifest facts — never generic ("good channel for devtools" is a failure; "security CLI + strong threat-model README is exactly HN's Show HN profile" is the standard).

Audience matching is mechanical first (manifest.audience.segments ∩ channel.audience), judgment second: a devtool can still be no-go on Product Hunt if it has no visual story, and a niche channel can be go on a weak intersection if the census notes say so. State which rule decided.

2. Sequencing — D-7 → D+7

Only go and blocked-by-gap (with scheduled fix) channels enter the timeline. Anchor: launch_date: null until the user picks D-0; all entries use relative days (D-7 … D+7) so scripts/make-ics.mjs can materialize real timestamps later.

Phase logic (adapt to the project, don't fill slots mechanically):

1. D-7 → D-3, preparation: gap fixes from the gap report (worst first — they gate everything downstream), account confirmations, github-meta groundwork (description, topics, release, social preview), kit review.
2. D-2 → D-1, soft launch: low-blast-radius channels that tolerate iteration — own communities (Telegram/Discord), Bluesky/Mastodon warm-up post, dev.to draft finalized. Purpose: catch broken links and weak copy before the big day.
3. D-0, main event: the single highest-leverage channel for this project (usually Show HN for devtools; Product Hunt for consumer/SaaS). Never stack two author-participation channels (HN + PH) on the same day — the author can't be in two comment threads at once.
4. D+1 → D+7, follow-up: second-tier communities (Reddit per-subreddit, spaced out — never simultaneous), long-tail directories (SaaSHub/AlternativeTo, DevHunt on its weekly cutoff, launch-directories queue), the technical launch post (dev.to/Hashnode) if not used earlier, and a results follow-up where honest.

Each timeline action: day, channel (or null for prep), type (prep | assisted | auto | manual), title, details (specific: what artifact, what precondition it satisfies), and — when the channel has timing advice — BOTH time_utc (canonical, straight from timing_advice; this is what make-ics consumes) and time_local (the same instant in the plan's timezone, DST-correct for the anchored season). Never render a time in only one of the two; PLAN.md shows both, e.g. "14:00–16:00 UTC (16:00–18:00 Europe/Rome)".

Channel-internal targets named by the router (specific subreddits, specific niche communities) are provisional inferences from the manifest audience. Mark them as such in the plan. At kit time each one must be validated against the venue's actual live rules (posting policy, flair, self-promotion clauses) before its kit is generated, and the kit must cite the verified rule — see the copywriting skill.

Sequencing rationale is part of the output: PLAN.md gets a short "Why this order" section (2-5 sentences grounded in this project's facts).

3. Rules

• Verdicts must cover all channels — count them and say "N channels: X go, Y blocked-by-gap, Z no-go (of which W no-go-by-choice)" in PLAN.md.
• Validate the plan before presenting it: node scripts/validate-manifest.mjs launches/<slug>/plan.yaml (the validator auto-detects plan files).
• Never schedule an assisted or excluded channel as an automated action. auto channels appear as type: auto and still require per-action confirmation at execution time (see CLAUDE.md, Ethics).
• Reddit: each subreddit is its own action on its own day; mass cross-posting is an excluded pattern.
• Don't pad: a project with 6 real channels gets 6, not 26.
• PLAN.md ends with "Next: /launch-kit <slug>".