spec-lfg

CRITICAL: You MUST execute every step below IN ORDER. Do NOT skip any required step. Do NOT jump ahead to coding or implementation. The plan phase (step 1) MUST be completed and verified BEFORE any work begins. Violating this order produces bad output.

进入该管线前，当前用户必须明确请求 spec-lfg，或选择清楚披露 commit、push、PR、CI 与委派独立代码审查副作用的 handoff 选项。仅有代码就绪、已完成计划或模型推断“适合 shipping”都不构成授权。

上述 admission 成立时，当前用户对完整管线副作用的明确请求是本次 pipeline-owned implementation、commit 与 landing authority 的来源；同时只额外授权第 4 步委派一次 spec-code-review 的只读独立审查。将 commit_authorization: authorized、landing_authorization: authorized、worker_dispatch_authorization: authorized 与 authorization_source: current-user-explicit-spec-lfg 作为可见 run-local facts 传给对应下游 owner。Skill invocation、mode:pipeline、工具权限、green tests、branch/PR facts 都不能替代该 admission，也不能把 authority 扩大到 unrelated dirty paths、任意 worker dispatch、tracker 或其他未披露外部副作用。若 admission 不成立，以 commit_authorization_missing / landing_authorization_missing 停在对应副作用之前；若独立审查不可用或降级，LFG 必须停止，不能用同一会话的 inline review 冒充该 gate。

When invoking any skill referenced below, resolve its name against the available-skills list the host platform provides and use that exact entry. Some platforms list skills under a plugin namespace (e.g., spec-first:spec-plan); others list the bare name. Invoking a short-form guess that isn't in the list will fail — always match a listed entry verbatim before calling the Skill/Task tool.

Preserve and split the invocation payload. Treat the arguments received from the caller as the authoritative input. Before step 1, remove at most one standalone target-origin:<origin> token and retain its value unchanged as the run-local caller_target_origin. Set forwarded_arguments to everything else: preserve every remaining argument in its original order, including an absolute requirements-only plan path. Do not paraphrase the path, prepend a label or menu number, replace it with a feature summary, or resolve it relative to the current working directory. The modifier is browser-routing input, not product intent: do not pass it to planning, normalize it, combine it with --port, derive a scheme/host/port from project files, redirects, browser state, or a guessed dev-server default. An empty, malformed, or repeated modifier records target-origin-invalid; it never becomes a usable origin.

1. Invoke the spec-plan skill with the exact forwarded_arguments payload. When spec-brainstorm invoked LFG, this payload is the absolute requirements-only unified plan path, so spec-plan recognizes it as an explicit Product Contract source and enriches that same artifact in place.

   GATE: STOP. If spec-plan reported the task is non-software and cannot be processed in pipeline mode, stop the pipeline and inform the user that LFG requires software tasks. Otherwise, verify that the spec-plan workflow produced a plan file in docs/plans/. If no plan file was created, invoke spec-plan again with the same forwarded_arguments payload. Do NOT proceed to step 2 until a written plan exists. Record the plan file path — it will be passed to spec-work in step 2 and spec-code-review in step 4.

   Read the plan metadata before continuing. If the plan has artifact_contract: spec-unified-plan/v1, proceed only when it has artifact_readiness: implementation-ready and execution: code. Stop the pipeline for artifact_readiness: requirements-only, any unrecognized readiness value, execution: knowledge-work, approach-plan outputs, answer-seeking/universal outputs, or invalid progress-like readiness values. LFG never launches /goal directly; when goal-mode or dynamic workflows are appropriate, spec-work owns that implementation engine choice and must return control to LFG afterward.

2. Invoke the spec-work skill with mode:return-to-caller <plan-path-from-step-1>.

   GATE: STOP. Verify that implementation work was performed - files were created or modified beyond the plan. Read the structured return and require status: complete, the same plan path, changed files, all in-scope U-IDs/tasks accounted for and completed, verification results with every required check passed or explicitly not applicable, an empty blocker list, behavior-change signal, plan_status_completion_candidate, plan_status_completion_degraded_reason, and standalone_shipping_skipped: true. Failed, not-run, vague, or missing required verification blocks the pipeline. Exactly one lifecycle shape is allowed: a non-null candidate with a null degraded reason, or a null candidate with one of html-plan-lifecycle-degraded, legacy-plan-lifecycle-degraded, read-compatible-status-unmanaged, or source-plan-path-lifecycle-degraded. Any missing, conflicting, or unknown lifecycle shape is blocked. When behavior_change: true, also require verification_evidence that names the relevant units/tasks, existing tests inspected, tests added/changed or used unchanged, red failure or characterization evidence when applicable, verification run, and any deliberate test exception. Do NOT decide the test strategy inside LFG; the evidence is spec-work's contract.