# 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.
