Codename-11 · Jul 13, 2026 · Jul 13, 2026 · Jul 13, 2026 · Jul 13, 2026
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -11,6 +11,22 @@ date, grouped by `Added` / `Changed` / `Fixed` / `Removed`.
 
 ## [Unreleased]
 
+## [2026-07-13] — v0.9.0 · Context-aware plans & issue archive
+
+### Added
+
+- **Plan-created issues now explain the work around them.** Issue detail shows the source Goal, Plan, step instructions, completion contract, dependencies, dependents, and sibling progress. Agents receive the same bounded context as an immutable run snapshot, so later plan edits cannot rewrite what an in-flight or historical run was told.
+- **Issues can be archived and restored cleanly.** The Issues page has an archived-only view with individual and bulk restore. Archive removes work from active views, clears queue and claim state, closes live agent work, and safely synchronizes an unambiguous materialized plan step while preserving history and relationships.
+
+### Changed
+
+- **Plan execution now enforces its declared constraints.** Crew concurrency is capped across all of a crew's active plans; dependencies and cross-workspace references are validated; role assignment never guesses between ambiguous crew members; and materialized Issue/ExecutionStep terminal state stays synchronized in both directions.
+- **Issue capture and bulk handling are more predictable.** Board and status-group quick-create preserve their originating status, command-palette creation stays in issue mode, MCP creation accepts status and labels within narrowed-key lanes, counts refresh with mutations, and bulk selection accurately says “Select loaded.”
+
+### Fixed
+
+- **Archived work can no longer leak back into agent or editing surfaces.** MCP issue/context tools, agent inboxes, comments, labels, relations, assignment, queueing, slash commands, and bulk status changes now respect the archive boundary. Comment deletion is tenant-scoped and label assignment rejects foreign-workspace labels.
+
 ## [2026-07-11] — v0.8.2 · Plan recovery ordering
 
 ### Fixed

diff --git a/DEVLOG.md b/DEVLOG.md
@@ -2,6 +2,49 @@
 
 > Append-only session log. Read at session start. Update at session end.
 
+## 2026-07-13 — Plan context integrity + reversible issue archive
+
+Closed the execution-context gaps that let materialized plan issues look like
+standalone tasks, then carried the same integrity pass through issue creation,
+handling, and archive/restore.
+
+- **Durable plan context.** Materialized issue detail now shows Goal → Plan →
+  Step provenance, instructions, output/verification contracts, dependencies,
+  dependents, and sibling progress. Agent runs capture a versioned immutable
+  orchestration-context snapshot at dispatch; inbox and MCP context prefer that
+  snapshot so later plan edits cannot rewrite a run's instructions.
+- **Orchestration invariants.** Step dependencies, assignees, roles, and source
+  runs are workspace/plan validated; structural edits are draft-only; role
+  resolution never guesses between multiple crew members. Crew `maxParallel`
+  is enforced across all of a crew's plans under row locks, with fair refill.
+  Materialized Issue and ExecutionStep terminal lifecycle now synchronizes in
+  both directions, including reaper/abandon paths.
+- **Reversible issue archive.** Added `issue.archive`, `restore`, and
+  `bulkRestore`, an archived-only Issues view, archived detail tombstones, and
+  single/bulk restore. Archive atomically clears queue/claim/snooze state,
+  abandons live runs, cancels one unambiguous active materialized step, and
+  records audit/activity; restore returns visibility without resurrecting old
+  work. MCP, agent inbox, relations, comments, labels, and active mutations now
+  respect the archive boundary. Added migrations `0097` (run context snapshot)
+  and `0098` (archive-list index).
+- **Issue-flow cleanup.** Board/status quick-add preserves its originating
+  status; command-palette create always opens issue mode; MCP create accepts
+  status/labels and enforces narrowed-key creation lanes; bulk copy says
+  “Select loaded”; list/count invalidation stays coherent. Reversible archive
+  confirmations no longer use destructive type-to-confirm friction. Comment
+  deletion is now tenant-scoped and label assignment validates workspace ids.
+- **Usability evidence.** The flow pass was grounded in the live deployment
+  behavior already inspected plus current UI/contracts and existing Forge
+  components/tokens. No screenshot-based browser audit was claimed because an
+  in-app browser surface was unavailable; Playwright CLI was intentionally not
+  substituted without an explicit browser choice.
+
+Verification: Prisma validate/format, `pnpm lint` (existing repository warnings
+only), `pnpm typecheck`, the full Vitest suite (**1,149 passed; 1 skipped**),
+`git diff --check`, a fresh Next.js production build, and the full Playwright
+suite (**37 passed**). Prepared as the v0.9.0 production release; rollout and
+live smoke verification follow the merge to `main`.
+
 ## 2026-07-11 — Recoverable agent review handoff
 
 Closed the Plan state-machine gap where a step could say “Needs review” after
@@ -12194,3 +12237,47 @@ reconciliation mutation occurred: PostgreSQL's descending sort places null
 the newer COMPLETED run. v0.8.2 orders attempts by `lastEventAt` instead (set on
 every run state) and adds the exact stalled-then-completed history to the
 watchdog regression fixture.
+
+## 2026-07-13 — Plan-linked issue context and orchestration integrity
+
+Inspected the current `forge` and `forge-worker` production services, the live
+Rich Rendering goal/plan, current source, and orchestration references. Live
+data confirmed that materialized plan-step issues retained only a small plan
+backlink: four DONE steps still had BACKLOG issues, dependency edges were not
+visible on issue Relations, runtime prompts omitted Goal/Plan/DAG context, and
+terminal STALLED runs could be selected as an agent's current run.
+
+- Added a bounded shared orchestration-context builder used by provider runtime
+  starts/resumes, `agent.inbox.list`, and `agent.context.bundle`. It includes
+  Goal/Plan/Step contracts, retry feedback, dependency/dependent issue links,
+  completed worker evidence, and non-excluded ContextSet refs without guessing
+  a step for multi-step plan-anchor issues.
+- Materialized issue detail now renders a primary Goal → Plan → Step context
+  card with success criteria, instructions, completion/verification contract,
+  feedback, sibling progress, and navigable dependencies. The Relations graph
+  derives plan dependency edges from `dependsOnStepIds` without persisting
+  duplicate `IssueRelation` rows.
+- Runtime-only planners with a linked Goal issue now open durable DISCUSS runs
+  and receive the decompose prompt; unanchored runtime planners are reported as
+  non-dispatchable instead of queueing a webhook guaranteed to dead-letter.
+  Worker/reviewer evidence and the planner trigger survive runtime handoff.
+- Ordinary assignment of a materialized issue synchronizes its intended step
+  worker, but TODO/BLOCKED/REVIEW or non-running-plan steps are scheduled rather
+  than dispatched. Only readiness can open the step-bound execution run.
+  Both inbox delivery and the background runtime scanner honor that gate;
+  provider/output start now audits READY → RUNNING.
+- Current-run resolution is limited to ACTIVE/WAITING and the linked agent.
+  Verdicts require a REVIEW step on the active RUNNING attempt; agent verdicts
+  additionally require that agent's active REVIEW run. CANCELED steps no longer
+  count toward Goal achievement.
+- Added safety guards around live-plan archive/delete and step removal, routed
+  RUNNING transitions through activation, validated updated ContextSet scope,
+  and fixed initiative-only API-key narrowing for issue reads/list filters.
+- Updated orchestration, engagement-mode, primitive, and MCP reference docs to
+  match the delivered behavior and to state honestly that crew `maxParallel`
+  remains informational rather than enforced.
+
+Verification: lint and typecheck passed; 1,126 unit/integration tests passed
+(one live-only test skipped); and a forced fresh production build plus all 37
+Playwright tests passed. This change is local only; production was inspected
+read-only and was not deployed or mutated.
diff --git a/docs/agents/engagement-modes.md b/docs/agents/engagement-modes.md
@@ -1,16 +1,16 @@
 # Engagement Modes
 
-> Set a mode when you assign or mention an agent to say *how far* you want the
+> Set a mode when you assign or mention an agent to say _how far_ you want the
 > work taken. Configure the defaults in **Settings → Dispatch Rules**. The
 > resolved mode rides on the `AgentRun` and shows as a chip on the run strip and
 > in Mission Control.
 
 ## Why modes exist
 
-When you hand an agent some work, the agent knows *what* you wrote — never *how
-far* you want it taken. Without a mode, every dispatch surface tells the agent
-essentially the same thing: *"You're assigned this issue. Work it, then
-summarise."* So the agent picks the safest-for-it reading: **do the whole
+When you hand an agent some work, the agent knows _what_ you wrote — never _how
+far_ you want it taken. Without a mode, every dispatch surface tells the agent
+essentially the same thing: _"You're assigned this issue. Work it, then
+summarise."_ So the agent picks the safest-for-it reading: **do the whole
 thing, to its own interpretation, right now.**
 
 That guess is wrong as often as it's right. Sometimes you want a full build.
@@ -27,12 +27,12 @@ run the completion gates.
 
 ## The four modes
 
-| Mode | Intent | What the agent may do | "Done" means |
-|------|--------|------------------------|--------------|
-| **Execute** | Do the work to completion | Edit code, transition status, open PRs/artifacts | Issue moved to review/done; `runs.complete` with artifacts; honors `artifactRequired` + `verificationChecklist` |
-| **Research** | Investigate & report | Read, search, run read-only tools | A findings comment **with a confidence flag**; issue status untouched |
-| **Review** | Critique existing work | Inspect a PR/diff/issue, judge it | A verdict (approve / request changes) |
-| **Discuss** | Answer / weigh in | Reply in-thread, ask questions | A reply comment; no work product |
+| Mode         | Intent                    | What the agent may do                            | "Done" means                                                                                                    |
+| ------------ | ------------------------- | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------- |
+| **Execute**  | Do the work to completion | Edit code, transition status, open PRs/artifacts | Issue moved to review/done; `runs.complete` with artifacts; honors `artifactRequired` + `verificationChecklist` |
+| **Research** | Investigate & report      | Read, search, run read-only tools                | A findings comment **with a confidence flag**; issue status untouched                                           |
+| **Review**   | Critique existing work    | Inspect a PR/diff/issue, judge it                | A verdict (approve / request changes)                                                                           |
+| **Discuss**  | Answer / weigh in         | Reply in-thread, ask questions                   | A reply comment; no work product                                                                                |
 
 These map onto primitives Forge already has — they don't add a parallel
 universe. **Research** leans on the existing confidence flag; **Review** leans
@@ -43,7 +43,7 @@ on review gates / action requests; **Execute** leans on `expectedOutput` /
 "Do the work but stop before the irreversible step" is **Execute + an
 approval/review gate**, not a fifth mode. Set `requireApprovalBeforeStart` or
 open a review gate on the deploy step. Deploy-safety stays orthogonal to mode,
-so it composes with *all* modes.
+so it composes with _all_ modes.
 :::
 
 ## Where the mode lives
@@ -55,22 +55,22 @@ prompt, and read by the watchdog, the auto-transition logic, and Mission
 Control.
 
 This is distinct from `Workspace.autoDispatchMode` (ROUND_ROBIN /
-CAPABILITY_MATCH / … — which decides *which agent gets picked*). Engagement mode
-is *what the picked agent is asked to do*. Different axis.
+CAPABILITY_MATCH / … — which decides _which agent gets picked_). Engagement mode
+is _what the picked agent is asked to do_. Different axis.
 
 ## Defaults by surface
 
-Defaults depend on *how* the work was dispatched — "mentions talk, assignments
+Defaults depend on _how_ the work was dispatched — "mentions talk, assignments
 act":
 
-| Surface | Entry point | Default mode | Why |
-|---------|-------------|--------------|-----|
-| **Assignment** | assign an agent → `AGENT_ASSIGNED` | **Execute** | Assigning *is* handing over the work |
-| **Queue / auto-dispatch** | queued issue + auto-dispatch | **Execute** | Queued = ready to be worked |
-| **@-mention in a comment** | mention in a comment | **policy-driven** (below) | A mention is a tap on the shoulder, not a work order |
-| **Chat** | Mission Control chat | **Discuss** | Chat is conversational by nature |
-| **Goal / plan step / crew** | plan or crew dispatch | **the step's mode**, else **Execute** | A plan declares its own intent per step |
-| **Watcher fan-out** | stalled / priority change / … | **awareness only** | Watchers observe; they don't get a work order |
+| Surface                     | Entry point                        | Default mode                                   | Why                                                                                           |
+| --------------------------- | ---------------------------------- | ---------------------------------------------- | --------------------------------------------------------------------------------------------- |
+| **Assignment**              | assign an agent → `AGENT_ASSIGNED` | **Execute**                                    | Assigning _is_ handing over the work                                                          |
+| **Queue / auto-dispatch**   | queued issue + auto-dispatch       | **Execute**                                    | Queued = ready to be worked                                                                   |
+| **@-mention in a comment**  | mention in a comment               | **policy-driven** (below)                      | A mention is a tap on the shoulder, not a work order                                          |
+| **Chat**                    | Mission Control chat               | **Discuss**                                    | Chat is conversational by nature                                                              |
+| **Goal / plan step / crew** | plan or crew dispatch              | **Execute** for workers; **Review** for judges | Worker and judge roles define the run intent; `ExecutionStep` does not store a separate mode. |
+| **Watcher fan-out**         | stalled / priority change / …      | **awareness only**                             | Watchers observe; they don't get a work order                                                 |
 
 Every default is overridable per dispatch, and the assignment + mention defaults
 are configurable per workspace.
@@ -80,7 +80,7 @@ are configurable per workspace.
 A mention is the one surface where teams genuinely disagree, so it's a workspace
 policy — `Workspace.mentionEngagementPolicy`:
 
-- **Infer** *(default)* — no explicit marker → the agent infers intent from the
+- **Infer** _(default)_ — no explicit marker → the agent infers intent from the
   comment, **and if it's ambiguous, asks before doing anything irreversible.**
   Maximum fluidity; the "ask first" clause is the safety net. This is the direct
   antidote to "it assumed I wanted it fully built."
@@ -109,11 +109,11 @@ Each mode has a canonical instruction block injected into the agent's turn (via
 `RunInput.instructions`, prepended in the dispatcher) and surfaced in
 `agent.context.bundle` so pull-based agents see it too. For example:
 
-- **Research:** *"This is a research pass. Investigate and report your findings
+- **Research:** _"This is a research pass. Investigate and report your findings
   as a comment with a confidence flag. Do not modify code, move the issue, or
-  open a PR. If you believe execution is warranted, say so and stop."*
-- **Execute:** *"Take this to completion. The definition of done is in
-  `expectedOutput`; verify against `verificationChecklist`."* (+ artifact /
+  open a PR. If you believe execution is warranted, say so and stop."_
+- **Execute:** _"Take this to completion. The definition of done is in
+  `expectedOutput`; verify against `verificationChecklist`."_ (+ artifact /
   approval clauses when set.)
 
 Forge also injects the shared run protocol, including a contract version:
@@ -196,7 +196,7 @@ is reused everywhere, with the warm-earthy tokens:
 - [Agents overview](/agents/overview.html) — the two ways to run agent work
   (direct dispatch vs. Goal orchestration), both riding on `AgentRun`.
 - [Auto-dispatch](/agents/auto-dispatch.html) — queued issues default to
-  Execute; how an agent gets *picked* (a different axis from mode).
+  Execute; how an agent gets _picked_ (a different axis from mode).
 - [Dispatch Rules](/agents/dispatch-rules.html) — where the mode defaults and
   mention policy are configured.
 - [SLAs & Watchdogs](/agents/slas-and-watchdogs.html) — why a Research run isn't