agentic-orchestrator 0.1.27 → 0.2.0

package/spec-files/completed/agentic_orchestrator_focus_plan_tab_intake_planning_workspace_spec.md

@@ -0,0 +1,921 @@
+# Agentic Orchestrator Focus Intake/Planning Tabs Workspace Spec
+
+> Purpose: Redesign the Focus page planning surface so it accurately models the planner lifecycle as two distinct subphases, `intake` and `planning`, using two distinct focus tabs instead of one overloaded Plan tab.
+
+## 1. Context
+
+The planner no longer has one monolithic "planning" phase.
+
+It now has two sequential subphases:
+
+1. `intake`
+2. `planning`
+
+`intake` produces and verifies the requirements contract.
+`planning` produces and maintains the accepted execution plan against that verified contract.
+
+The current Plan tab in `packages/web-dashboard/src/components/focus/` still reflects the old mental model:
+
+- `Source Spec`
+- `Plan Progress`
+- `Accepted Plan`
+
+That was acceptable when "plan" meant one artifact.
+It is no longer acceptable now that the system distinguishes:
+
+- raw spec input
+- bootstrap manifest
+- verified manifest
+- accepted execution plan
+
+The current Plan tab therefore hides the most important operator question:
+
+`Are we still validating requirements, or are we already planning execution?`
+
+## 2. Problem Statement
+
+The existing Plan tab is structurally wrong for the new lifecycle.
+
+### 2.1 Current UX failures
+
+- The tab assumes a single accepted-plan contract instead of a two-step contract formation flow.
+- `PlanProgressPanel` is too generic and is not intake-aware.
+- `buildPlanProgressSummary()` currently derives build/QA/review-era tasks, which is misleading when the feature is still in `intake` or `planning`.
+- Intake state is shown as a lightweight summary in `OverviewTab`, but the actual deep workspace for intake/planning decisions is still missing.
+- The verified requirements contract is not visually elevated above the raw source spec once intake is complete.
+- The accepted plan card does not tell the operator whether the plan is current to the verified manifest, whether it is stale, or whether traceability is complete.
+- The operator cannot easily answer "what changed during intake?" without reading raw JSON artifacts.
+- Open intake questions are not treated as a first-class Plan-tab concern even though they block the transition into execution planning.
+- Forcing both lifecycle stages into one tab collapses two different operator jobs into one screen and will create avoidable confusion.
+- The current cards are artifact-led, not decision-led.
+
+### 2.2 Consequence
+
+Operators cannot quickly determine:
+
+- which planner subphase is active
+- whether planning can begin
+- what is blocking promotion out of intake
+- whether the accepted plan is current and trustworthy
+- whether the accepted plan fully covers the verified obligations
+
+## 3. Scope and Supersession
+
+This spec updates the Focus-page planner-oriented surface in the feature focus view.
+
+It supersedes the one-stage Plan-tab assumptions from:
+
+- `spec-files/completed/agentic_orchestrator_feature_focus_view_track_c_decision_centric_remediation_spec.md` section 7
+
+It builds on, but does not replace, the intake lifecycle defined in:
+
+- `spec-files/outstanding/agentic_orchestrator_interactive_planning_intake_and_requirements_verification_spec.md`
+
+Normative rule:
+
+- `OverviewTab` may keep a lightweight intake summary.
+- The old single `Plan` tab must be split into a dedicated `Intake` tab and a dedicated `Planning` tab.
+- Those two tabs become the primary deep-detail workspace for planner-owned work.
+
+## 4. UX Goals
+
+The redesigned Intake and Planning tabs must optimize for operator decisions, not artifact dumping.
+
+### 4.1 The top of the tab must answer
+
+1. Which planner subphase is active right now?
+2. Is the feature blocked in intake, actively planning, or ready for build?
+3. What is the single next thing required to advance the planner lifecycle?
+4. Which contract is authoritative right now:
+   - source spec
+   - bootstrap manifest
+   - verified manifest
+   - accepted plan
+5. Is the accepted plan current to the verified requirements contract?
+
+### 4.2 The tab must reduce cognitive load
+
+- It must not force the operator to interpret raw JSON before understanding status.
+- It must not show build/QA/review tasks as the current plan state when the feature is still in `intake` or `planning`.
+- It must not make the raw source spec look equally authoritative to the verified manifest after intake is complete.
+
+### 4.3 The tab must preserve auditability
+
+- Raw artifacts must remain available.
+- Their provenance, version, and timestamps must be visible.
+- Derived summaries must always link back to concrete artifacts.
+
+## 5. Non-Goals
+
+- This spec does not redesign the Overview, Runtime, Review, or History tabs beyond the Plan-tab handoff points they already depend on.
+- This spec does not introduce in-browser artifact editing.
+- This spec does not change kernel lifecycle invariants.
+- This spec does not replace the existing question protocol; it only repositions intake/planning question context in the Plan tab.
+
+## 6. Information Architecture
+
+The old single `Plan` tab must be removed as the primary planner workspace.
+
+It is replaced by two distinct tabs:
+
+1. `Intake`
+2. `Planning`
+
+Reason:
+
+- `intake` and `planning` are different operator jobs
+- they have different contracts
+- they have different blockers
+- combining them into one tab invites confusion and weakens prioritization
+
+## 6.1 Tab model
+
+### 6.1.1 Required tabs
+
+Add two focus tabs:
+
+- `intake`
+- `planning`
+
+Preferred user-facing labels:
+
+- `Intake`
+- `Planning`
+
+The old `plan` tab id should be retired rather than relabeled.
+
+### 6.1.2 Visibility rules
+
+The `Intake` tab must be visible when any of the following are true:
+
+- feature phase is `intake`
+- feature phase is `awaiting_input` and `resume_status=intake`
+- intake artifacts exist
+- intake summary exists
+
+The `Planning` tab must be visible when any of the following are true:
+
+- feature phase is `planning`
+- feature phase is `building`, `qa`, `ready_to_merge`, or `merged`
+- a verified manifest exists
+- a plan exists
+
+### 6.1.3 Default-tab rules
+
+Default active tab must be:
+
+- `Intake` when the feature is in `intake`
+- `Intake` when the feature is `awaiting_input` for intake
+- `Planning` when intake is verified and planning is active or later
+
+The user must not land on `Planning` first while intake is still unresolved.
+
+## 6.2 Shared planner lifecycle header
+
+Both tabs must render the same `PlannerLifecycleHeader` at the top.
+
+This shared header prevents the two-tab design from feeling disconnected.
+
+### 6.2.1 Decision banner
+
+The banner must produce one primary state, not a bag of badges.
+
+Allowed primary banner states:
+
+- `Waiting on intake clarification`
+- `Intake in progress`
+- `Ready for execution planning`
+- `Execution planning in progress`
+- `Accepted plan is current`
+- `Accepted plan is stale`
+
+The banner must include:
+
+- current subphase
+- primary blocker or readiness statement
+- current owner:
+  - `planner`
+  - `operator`
+  - `system`
+- last subphase update timestamp
+- a clear next-action sentence
+
+### 6.2.2 Lifecycle stepper
+
+The header must render a five-step horizontal or stacked stepper:
+
+1. `Source Spec`
+2. `Bootstrap Manifest`
+3. `Verified Manifest`
+4. `Accepted Plan`
+5. `Execution`
+
+Each step must be one of:
+
+- `complete`
+- `current`
+- `blocked`
+- `pending`
+
+Normative rule:
+
+- when `phase=intake`, steps 4 and 5 must not appear "in progress"
+- when `phase=planning`, step 3 may be `complete`, step 4 may be `current`, and step 5 must remain `pending`
+
+## 6.3 Intake tab
+
+The `Intake` tab is the primary surface whenever the feature is in `intake` or `awaiting_input` with `resume_status=intake`.
+
+### 6.3.1 Required sections
+
+1. `Requirements Intake Summary`
+2. `Ambiguity Queue`
+3. `Promotion Readiness`
+4. `What Changed During Intake`
+5. `Intake Artifacts`
+
+### 6.3.2 Requirements Intake Summary
+
+This card must show:
+
+- intake status
+- bootstrap manifest version
+- verified manifest version
+- obligation count in bootstrap manifest
+- obligation count in verified manifest
+- open ambiguity count
+- questions open / resolved
+- promotion basis
+- last verified timestamp
+
+The promotion basis must be mapped into human language:
+
+- `structured_spec` -> `Promoted directly from a structured spec`
+- `questions_resolved` -> `Promoted after intake questions were resolved`
+- `policy_approved_auto_promotion` -> `Auto-promoted by policy`
+- `human_review_confirmed` -> `Promoted after explicit human review`
+
+The raw enum string must not be the primary display.
+
+### 6.3.3 Ambiguity Queue
+
+This card must make ambiguity state actionable.
+
+Each ambiguity row must show:
+
+- ambiguity id
+- summary
+- status
+- linked obligation ids
+- whether it is blocking promotion
+- whether a linked open intake question exists
+
+Rows must be grouped into:
+
+- `Open`
+- `Resolved`
+
+If there are no ambiguities, the card must say so explicitly.
+
+### 6.3.4 Answering mechanism in the Ambiguity Queue
+
+The ambiguity queue itself must provide the operator mechanism for answering open intake questions.
+
+Normative rule:
+
+- the operator must be able to answer a linked open intake question directly from the relevant ambiguity row
+- the operator must not need to hunt for a separate detached human-input card elsewhere on the page
+
+Preferred behavior:
+
+- each open ambiguity row with a linked open intake question shows an `Answer` or `Resolve` action
+- clicking that action expands an inline answer panel scoped to that ambiguity
+- the inline answer panel reuses `HumanInputPanel` behavior and transport
+
+The inline answer panel must show:
+
+- question prompt
+- role and phase
+- ambiguity id
+- linked obligation ids
+- expected answer choices or schema hints
+- resume target
+
+If an intake-blocking question exists without an `ambiguity_id`, the tab must render a fallback `General Intake Question` section immediately below the queue.
+
+### 6.3.5 Promotion Readiness
+
+This card must answer:
+
+- can intake promote into execution planning right now?
+
+It must show:
+
+- `Ready` or `Blocked`
+- blocker reasons as a flat list
+- whether a verified manifest exists
+- whether open intake questions remain
+- whether unresolved ambiguities remain
+
+It must not show a fake percentage.
+
+### 6.3.6 What Changed During Intake
+
+This card replaces raw-manifest comparison as the default first view.
+
+It must summarize the delta from bootstrap -> verified:
+
+- ambiguities resolved count
+- ambiguities still open count
+- obligations added
+- obligations removed
+- confidence upgrades
+- confidence downgrades
+
+First rollout may be summary-only.
+
+Raw JSON diff is optional and should remain behind a disclosure.
+
+### 6.3.7 Intake Artifacts
+
+The Intake tab must own its own artifact viewer.
+
+Required artifact tabs:
+
+1. `Source Spec`
+2. `Bootstrap Manifest`
+3. `Verified Manifest`
+4. `Intake Review`
+
+Presentation rules:
+
+- `Source Spec` renders with the shared markdown renderer
+- manifests and review artifacts render in a pretty-printed JSON viewer
+- every artifact view must show path, version, and last-updated timestamp
+- every artifact view must expose `Open raw`
+
+Authority rule:
+
+- once intake is verified, `Verified Manifest` is the requirements contract of record
+- `Source Spec` becomes a reference input, not the primary contract
+
+## 6.4 Planning tab
+
+The `Planning` tab is the primary surface whenever the feature is in `planning` or later and a verified manifest exists.
+
+### 6.4.1 Required sections
+
+1. `Execution Planning Summary`
+2. `Plan Contract Health`
+3. `Plan Trace Coverage`
+4. `Current Planning Focus`
+5. `Accepted Execution Plan`
+6. `Planning Artifacts`
+
+### 6.4.2 Intake handoff summary
+
+The Planning tab must include a slim, non-dominant handoff summary at the top of its body stating:
+
+- verified manifest version
+- promotion basis
+- last verified timestamp
+- open ambiguity count at handoff
+
+This is not a second full intake workspace.
+
+It exists only to anchor planning against the verified contract.
+
+### 6.4.3 Execution Planning Summary
+
+This card must show:
+
+- planning status:
+  - `not started`
+  - `ready to plan`
+  - `in progress`
+  - `accepted`
+  - `stale`
+  - `blocked`
+- accepted plan version
+- accepted-plan timestamp
+- gate profile
+- scoped file counts:
+  - create
+  - modify
+  - delete
+- task count
+- risk count
+
+### 6.4.4 Plan Contract Health
+
+This card must answer:
+
+- is the accepted plan current to the latest verified manifest?
+
+It must surface:
+
+- verified manifest version
+- plan source verified-manifest version
+- stale/current outcome
+- mismatch reason
+
+Normative requirement:
+
+- the plan artifact or an adjacent derived read model must bind the accepted plan to a specific verified manifest version
+- dashboard UX must not infer "current" only from timestamp proximity if explicit version binding can be persisted
+
+Preferred contract additions to `plan.json`:
+
+- `source_verified_manifest_version`
+- `source_verified_at`
+
+### 6.4.5 Plan Trace Coverage
+
+This card must use `plan.plan_trace` when available.
+
+It must summarize:
+
+- total verified obligations
+- mapped obligations
+- unmapped obligations
+- deferred obligations
+- out-of-scope obligations
+- obligations missing planned verification intent
+
+The operator must be able to see which verified obligations are not yet represented in the accepted plan.
+
+The card must not require the operator to open raw `plan.json` to determine coverage.
+
+### 6.4.6 Current Planning Focus
+
+This card must answer:
+
+- what is the planner doing right now?
+- what remains before the plan is truly accepted?
+
+It must derive from:
+
+- explicit plan task state when present
+- planner worker events
+- plan version changes
+- verified-manifest freshness
+
+The card must show:
+
+- current planner focus line
+- next up to three planning tasks
+- blocked planning tasks, if any
+
+Important rule:
+
+- while the feature is still in `planning`, this card must not talk about implementation, QA, review, or merge as if they are the current work item
+- those belong to broader feature execution, not the planning subphase
+
+### 6.4.7 Accepted Execution Plan
+
+This replaces the current low-signal `Accepted Plan` card.
+
+It must become a planning contract card with:
+
+- plan summary
+- top acceptance criteria
+- scoped files preview
+- risks preview
+- owners or owner roles
+- raw task list
+
+If no accepted plan exists yet:
+
+- do not show an empty `Accepted Plan` shell
+- instead show `No accepted execution plan yet` plus the exact reason:
+  - intake not verified
+  - planning not started
+  - planning blocked
+
+### 6.4.8 Planning Artifacts
+
+The Planning tab must own its own artifact viewer.
+
+Required artifact tabs:
+
+1. `Verified Manifest`
+2. `Plan Markdown`
+3. `Plan JSON`
+
+Presentation rules:
+
+- `Plan Markdown` renders with the shared markdown renderer
+- `Verified Manifest` and `Plan JSON` render in a pretty-printed JSON viewer
+- every artifact view must show path, version, and last-updated timestamp
+- every artifact view must expose `Open raw`
+
+## 6.5 State behavior matrix
+
+### 6.5.1 `phase=intake`
+
+- `Intake` tab is primary
+- `Planning` tab may be visible but must not imply an accepted plan exists
+- planning sections should explain why planning cannot begin yet
+
+### 6.5.2 `phase=awaiting_input` with `resume_status=intake`
+
+- banner = `Waiting on intake clarification`
+- `Intake` tab is primary
+- ambiguity rows with linked open questions expose inline answer controls
+- promotion-readiness block is open by default
+
+### 6.5.3 `phase=planning`
+
+- banner = `Execution planning in progress`
+- `Planning` tab is primary
+- `Intake` tab remains available as the verified-contract audit trail
+
+### 6.5.4 `phase=building|qa|ready_to_merge|merged`
+
+- `Planning` becomes the historical contract section
+- `Intake` remains inspectable as provenance
+- header states that execution is operating against an accepted plan
+- if the plan is stale relative to the verified manifest, the stale warning must still appear
+
+## 7. Data Model and Derivations
+
+The current `FeatureDetail.plan_progress` is too shallow to power this UX.
+
+Normative rule:
+
+- keep `plan_progress` for lightweight overview widgets if desired
+- do not use it as the primary read model for the Intake or Planning tabs
+
+## 7.1 New read models
+
+Add three read models to `packages/web-dashboard/src/lib/types.ts`:
+
+1. `PlannerLifecycleSummary`
+2. `FeatureIntakeWorkspace`
+3. `FeaturePlanningWorkspace`
+
+Suggested shared shape:
+
+```ts
+type PlannerSubphase = 'intake' | 'planning' | 'post_planning';
+
+interface PlanLifecycleStep {
+  id: 'source_spec' | 'bootstrap_manifest' | 'verified_manifest' | 'accepted_plan' | 'execution';
+  label: string;
+  status: 'complete' | 'current' | 'blocked' | 'pending';
+  detail: string;
+}
+
+interface ManifestArtifactSummary {
+  version: number | null;
+  generated_at: string | null;
+  obligation_count: number;
+  ambiguity_count?: number;
+  verification_basis?: string | null;
+  confidence: {
+    high: number;
+    medium: number;
+    low: number;
+  };
+}
+
+interface PlannerLifecycleSummary {
+  current_subphase: PlannerSubphase;
+  current_owner: 'planner' | 'operator' | 'system' | null;
+  last_updated_at: string | null;
+  banner_state:
+    | 'waiting_on_intake_clarification'
+    | 'intake_in_progress'
+    | 'ready_for_execution_planning'
+    | 'execution_planning_in_progress'
+    | 'accepted_plan_current'
+    | 'accepted_plan_stale';
+  lifecycle_steps: PlanLifecycleStep[];
+  next_action: string;
+  primary_detail: string;
+}
+
+interface FeatureIntakeWorkspace {
+  lifecycle: PlannerLifecycleSummary;
+  summary: FeatureIntakeSummary | null;
+  review: FeatureIntakeReviewSummary | null;
+  bootstrap_manifest: ManifestArtifactSummary | null;
+  verified_manifest: ManifestArtifactSummary | null;
+  open_ambiguities: Array<{
+    id: string;
+    summary: string;
+    obligation_ids: string[];
+    blocking: boolean;
+    linked_open_question_id: string | null;
+  }>;
+  resolved_ambiguities: Array<{
+    id: string;
+    summary: string;
+    obligation_ids: string[];
+  }>;
+  promotion_readiness: {
+    ready: boolean;
+    blocker_reasons: string[];
+  };
+  manifest_delta: {
+    ambiguities_resolved: number;
+    ambiguities_open: number;
+    obligations_added: number;
+    obligations_removed: number;
+    confidence_upgrades: number;
+    confidence_downgrades: number;
+  };
+  open_questions: FeatureQuestion[];
+}
+
+interface FeaturePlanningWorkspace {
+  lifecycle: PlannerLifecycleSummary;
+  intake_handoff: {
+    verified_manifest_version: number | null;
+    promotion_basis: string | null;
+    last_verified_at: string | null;
+    open_ambiguity_count: number;
+  } | null;
+  status: 'not_started' | 'ready_to_plan' | 'in_progress' | 'accepted' | 'stale' | 'blocked';
+  accepted_plan_version: number | null;
+  accepted_at: string | null;
+  gate_profile: string | null;
+  task_count: number;
+  risk_count: number;
+  current_focus: string | null;
+  next_tasks: PlanProgressTaskSummary[];
+  blocked_tasks: PlanProgressTaskSummary[];
+  file_scope: {
+    create: number;
+    modify: number;
+    delete: number;
+    sample_paths: string[];
+  };
+  trace_coverage: {
+    total_obligations: number;
+    mapped: number;
+    unmapped: number;
+    deferred: number;
+    out_of_scope: number;
+    missing_verification_intent: number;
+  };
+  freshness: {
+    source_verified_manifest_version: number | null;
+    current_verified_manifest_version: number | null;
+    stale: boolean;
+    reason: string | null;
+  };
+}
+```
+
+## 7.2 Derivation rules
+
+### 7.2.1 Lifecycle derivation
+
+The shared lifecycle summary must derive from:
+
+- feature phase
+- intake summary
+- existence/freshness of verified manifest
+- existence/freshness of accepted plan
+- open intake questions
+- planner worker events
+
+### 7.2.2 Intake derivation
+
+The Intake read model must load and summarize:
+
+- `spec.md`
+- `spec.manifest.bootstrap.json`
+- `spec.manifest.verified.json`
+- `intake.review.json`
+- feature questions filtered to `resume_status=intake`
+
+Linked ambiguity question behavior:
+
+- if a question references `ambiguity_id`, bind it to that ambiguity row
+- if a question references obligation ids but not ambiguity id, show that relationship in row metadata when determinable
+
+### 7.2.3 Planning derivation
+
+The Planning read model must load and summarize:
+
+- `plan.md`
+- `plan.json`
+- `plan.plan_trace`
+- verified-manifest obligations
+- planner worker events
+
+### 7.2.4 Staleness
+
+Accepted-plan freshness must not be hand-wavy.
+
+Preferred rule:
+
+- stale if `plan.source_verified_manifest_version !== verified_manifest.manifest_version`
+
+Fallback rule only if version binding is unavailable:
+
+- stale if verified-manifest update is newer than the accepted plan and no later plan acceptance is recorded
+
+### 7.2.5 Progress semantics
+
+Do not reuse the current "implementation / verification / review / merge" progress model at the top of the planner tabs.
+
+For these tabs:
+
+- `Intake` progress concerns requirement verification and promotion only
+- `Planning` progress concerns accepted-plan quality and completeness only
+
+## 8. API and Loader Changes
+
+## 8.1 New routes
+
+Add:
+
+- `GET /api/features/[id]/planner-lifecycle`
+- `GET /api/features/[id]/intake-workspace`
+- `GET /api/features/[id]/planning-workspace`
+
+Reason:
+
+- separate tabs should load separate decision surfaces
+- intake and planning have different artifact mixes
+- this keeps tab ownership clean
+
+`planner-lifecycle` may be embedded in the tab-specific routes if duplication is simpler, but the ownership boundary must remain explicit.
+
+## 8.2 Existing route handling
+
+`/api/features/[id]/spec` may remain for raw artifact viewing.
+
+`/api/features/[id]/plan-progress` may remain for lightweight overview widgets, but neither new tab should depend on it as its primary source.
+
+## 8.3 Refresh behavior
+
+The Intake and Planning tabs must not introduce uncontrolled polling.
+
+Allowed refresh triggers:
+
+- initial tab mount
+- explicit refresh action
+- successful human-input answer submission
+- optional bounded polling only when:
+  - the relevant tab is active
+  - the feature is in `intake` or `planning`
+  - the interval is fixed and conservative
+
+## 9. Component Ownership
+
+## 9.1 Required Focus-page changes
+
+- `packages/web-dashboard/src/components/focus/FocusLayout.tsx`
+  - must mount two distinct tabs instead of the old single `PlanTab`
+- `packages/web-dashboard/src/components/focus/tabs/PlanTab.tsx`
+  - should be replaced by `IntakeTab.tsx` and `PlanningTab.tsx`
+- `packages/web-dashboard/src/components/focus/PlanProgressPanel.tsx`
+  - should be removed or split into lifecycle-specific summary components
+- `packages/web-dashboard/src/components/plan-viewer.tsx`
+  - should become planning-specific contract rendering, not a generic accepted-plan blob
+- `packages/web-dashboard/src/components/focus/SpecViewer.tsx`
+  - should no longer represent the entire planner surface by itself
+- `packages/web-dashboard/src/components/human-input-panel.tsx`
+  - must be reused inside the ambiguity-answer flow for intake
+
+## 9.2 New components expected
+
+- `PlannerLifecycleHeader`
+- `IntakeTab`
+- `PlanningTab`
+- `AmbiguityQueueCard`
+- `AmbiguityQuestionInlinePanel`
+- `PromotionReadinessCard`
+- `ManifestDeltaCard`
+- `PlanContractHealthCard`
+- `PlanTraceCoverageCard`
+- `IntakeArtifactViewer`
+- `PlanningArtifactViewer`
+
+Names may vary, but the responsibilities must be split along those boundaries.
+
+## 10. Copy, Formatting, and Layout Rules
+
+## 10.1 Labeling
+
+Use human-facing labels.
+
+Avoid leading with raw internal enum names such as:
+
+- `questions_resolved`
+- `policy_approved_auto_promotion`
+- `in_progress`
+
+Human-friendly text must be primary; raw values may be secondary metadata.
+
+## 10.2 Tab hierarchy
+
+- `Intake` and `Planning` must read as different operator workspaces, not as two arbitrary content buckets
+- each tab should have one dominant top summary
+- historical/raw artifact viewers must not compete with the summary cards for attention
+
+## 10.3 No fake precision
+
+- do not show a single overall percentage for the combined intake/planning lifecycle unless the underlying model is genuinely reliable
+- step-state or readiness-state presentation is preferred
+
+## 10.4 Authority cues
+
+After verified manifest promotion:
+
+- the verified manifest must read as the contract of record
+- the source spec must read as original input/reference
+
+## 11. Testing Strategy
+
+## 11.1 Derivation tests
+
+Add read-model tests for:
+
+- feature still in `intake`
+- feature awaiting intake input
+- intake verified but no accepted plan yet
+- planning active
+- accepted plan stale against newer verified manifest
+- accepted plan current and trace-complete
+
+## 11.2 Route tests
+
+Add route coverage for:
+
+- `GET /api/features/[id]/planner-lifecycle`
+- `GET /api/features/[id]/intake-workspace`
+- `GET /api/features/[id]/planning-workspace`
+- missing artifact fallback behavior
+- partial artifact states
+
+## 11.3 Component tests
+
+Add rendering tests proving:
+
+- intake state does not show implementation/QA/review as the current task
+- ambiguity rows with linked open questions expose inline answer actions
+- answering UI renders inside the `Intake` tab rather than in a detached planner card
+- verified manifest becomes primary after promotion
+- stale accepted-plan warning renders correctly in `Planning`
+- artifact viewers expose the required tab-specific artifacts
+
+## 11.4 Regression focus
+
+The tests must guard against:
+
+- the old failure mode where one combined tab implies a single accepted-plan workflow regardless of whether intake has finished
+- the ambiguity-queue failure mode where open questions are visible but not actionable
+
+## 12. Implementation Slices
+
+### 12.1 Slice A - Tab split and shared lifecycle header
+
+- add new focus-tab ids
+- split the old `PlanTab` into `IntakeTab` and `PlanningTab`
+- add shared lifecycle header
+
+### 12.2 Slice B - Intake workspace and inline answer flow
+
+- add intake read model and route
+- add intake summary, ambiguity queue, readiness, delta, and artifact viewer
+- wire linked open questions into inline ambiguity-row answer panels
+
+### 12.3 Slice C - Planning workspace
+
+- add planning read model and route
+- replace the generic accepted-plan card
+- add plan contract health
+- add plan trace coverage
+- add planning focus / remaining planner work
+
+### 12.4 Slice D - Artifact viewers and cleanup
+
+- separate intake/planning artifact ownership
+- add pretty JSON views where needed
+- remove stale one-stage assumptions from existing focus components
+
+### 12.5 Slice E - Tests and migration cleanup
+
+- update focus-layout and planner-tab tests
+- remove stale single-tab assumptions
+- ensure overview snapshots still use lightweight summaries only
+
+## 13. Acceptance Criteria
+
+1. The feature focus view exposes separate `Intake` and `Planning` tabs instead of one combined planning tab.
+2. When a feature is in `intake`, the `Intake` tab clearly states that intake is the active subphase and does not imply that an accepted execution plan already exists.
+3. When a feature is `awaiting_input` for intake, the operator can answer linked open intake questions directly from the relevant ambiguity row inside the `Intake` tab.
+4. If an intake-blocking question exists without a matching ambiguity row, the `Intake` tab still surfaces an immediately actionable fallback answer section.
+5. The top of both planner tabs explicitly answers whether the feature is blocked in intake, ready for planning, actively planning, or operating against a current accepted plan.
+6. The `Intake` tab visually distinguishes the authoritative requirements contract (`Verified Manifest`) from the raw source spec once intake is verified.
+7. The operator can understand what changed during intake without opening raw JSON artifacts.
+8. The `Planning` tab tells the operator whether the accepted plan is current to the verified manifest and why it is stale when it is stale.
+9. The `Planning` tab summarizes obligation-to-plan trace coverage from `plan_trace` instead of hiding that data in raw `plan.json`.
+10. The `Planning` tab no longer treats build/QA/review/merge work as the current planning task while the feature is still in planner-owned subphases.
+11. Intake and planning raw lifecycle artifacts remain inspectable from their owning tabs through tab-specific artifact viewers.
+12. The implementation includes component and loader regression coverage for intake, intake-answering, planning, stale-plan, and accepted-plan-complete states.