@moretea-labs/forge 1.5.0-rc.1 → 1.5.1

package/docs/architecture/current/dispatch-and-agent-strategy.md

@@ -66,14 +66,14 @@ search/read
   -> inspect aggregate diff
   -> focused checks
   -> finalize or rollback
-  -> Task verification when linked
+  -> Work verification when linked
 ```
 
 Direct Edit MUST use the same Workspace single-writer resource boundary as a Workspace Agent.
 
 ### 3.2 Quick Agent
 
-Quick Agent is used when the objective is clear but implementation requires meaningful exploration or repeated local edit/test cycles, without needing a durable multi-Task dependency graph.
+Quick Agent is used when the objective is clear but implementation requires meaningful exploration or repeated local edit/test cycles, without needing a durable multi-Work dependency graph.
 
 Preferred characteristics:
 
@@ -84,11 +84,11 @@ Preferred characteristics:
 - retry can replace the whole attempt;
 - Agent autonomy provides clear value over Direct Edit.
 
-Quick Agent work may use ephemeral Issue metadata, but Job and Run evidence remain durable.
+Quick Agent work may carry ephemeral diagnostic metadata, but Job and Run evidence remain durable.
 
-### 3.3 Issue and Task
+### 3.3 Requirement, Plan, and Work
 
-A durable Issue/Task graph is required when work has one or more of:
+A durable Requirement/Plan/Work graph is required when work has one or more of:
 
 - multiple independently verifiable objectives;
 - dependencies or ordered migration phases;
@@ -101,7 +101,7 @@ A durable Issue/Task graph is required when work has one or more of:
 - a need for review and recovery across multiple sessions;
 - release or rollout coordination.
 
-A durable Task is not ceremony. It is the unit that owns scope, dependencies, evidence, retry history, and acceptance.
+A durable Work contract is not ceremony. It owns bounded execution scope, dependencies, evidence, retry history, and completion receipts; Requirement owns user-visible intent and acceptance outcome.
 
 ## 4. Decision Order
 
@@ -111,7 +111,7 @@ The Controller applies this order:
 1. Is the request read-only?
 2. Can bounded Direct Edit safely satisfy it?
 3. Is one scoped Agent attempt sufficient?
-4. Does the work require a durable Task graph?
+4. Does the work require durable Requirement/Plan/Work state?
 5. Does it cross repositories or require a Schedule?
 6. Does any external or destructive boundary require human authorization?
 ```
@@ -234,15 +234,15 @@ Response policy:
 | Acceptance | Refine implementation, not the criteria unless product intent changed |
 | Integration | Preserve Worktree; repair from current target state |
 | Capability mismatch | Select a more suitable Agent/provider |
-| Controller contract | Re-plan Task before another Run |
+| Controller contract | Re-plan Work before another Run |
 
-## 8. Task Execution Contract
+## 8. Work Execution Contract
 
 Every Agent Run receives a generated contract containing:
 
 ```text
 repository and checkout identity
-Issue and Task objective
+Requirement and Work objective
 current implementation context
 allowed and forbidden paths
 required outputs
@@ -347,7 +347,7 @@ The dispatch layer MUST avoid:
 
 ## 13. Current Implementation
 
-The repository implements Direct Edit, Quick Agent and Issue/Task assessment; runtime Agent selection; bounded Task scope; persistent Runs; Workspace/Worktree placement; and risk-adaptive verification.
+The repository implements Direct Edit, Quick Agent and Requirement/Work assessment; runtime Agent selection; bounded Task scope; persistent Runs; Workspace/Worktree placement; and risk-adaptive verification.
 
 The Thin Gateway keeps deterministic local commands on Direct Edit or Process Runtime paths. Agent dispatch is now an explicit external-Controller handoff; the Kernel no longer creates Execution Jobs for ordinary Agent launches. Work ownership, repository placement, and resource claims remain durable Controller state, while provider selection and model execution belong to the claimed external Controller.
 

package/docs/architecture/current/entity-model.md

@@ -577,21 +577,6 @@ Ephemeral Quick Agent Issue metadata may be cleaned after terminal completion, b
 
 Runtime projections, expired Leases, caches, and disposable Worktrees may be removed after durable terminal evidence and cleanup records exist.
 
-## ChatGPT-Supervised Campaign
-
-A Campaign is a durable project-level objective that coordinates existing Tasks, Execution Jobs, Agent Runs, Evidence, and human acceptance without replacing their lifecycles.
-
-- A Campaign has revisioned goals and a stable goal hash.
-- A Campaign Task references one existing MCP operation and explicit dependencies.
-- A Checkpoint is a persisted ChatGPT review boundary, not a running Job.
-- A Supervisor Decision is bound to one checkpoint nonce and goal revision.
-- `waiting_for_supervisor` holds no worker or resource lease.
-- `ready_for_human_acceptance` is not completion; only explicit human acceptance transitions to `completed`.
-
-Campaign records are repository-scoped. Execution remains delegated to the existing durable Job and Agent Run models.
-
-A Campaign owns an immutable `workspace` binding containing mode, checkout id, branch, root, original base revision, and whether Forge manages the worktree. ExecutionJob workers must resolve `job.checkoutId`; falling back to the active checkout is an identity violation.
-
 ## 22. Structured Execution Outcome
 
 A Job result and a Job failure are separate concepts. Durable execution records may contain all of the following independently:
@@ -605,15 +590,3 @@ error                  terminal workflow error when the Job did not succeed
 ```
 
 Successful stdout is never stored in `error`. Compatibility Local Jobs project the durable Execution Job status, result, and structured outcome without becoming a second source of lifecycle truth.
-
-## 23. Campaign Completion Outcome
-
-A Campaign Task distinguishes an implementation change from an already-satisfied objective:
-
-```text
-succeeded              completed with changes or a non-repository result
-succeeded_no_change    completed with a proven empty repository diff
-failed_no_effect       changes were required but the Run produced no diff
-```
-
-`requiresChanges` is part of Task intent. A no-change Task never opens a review solely because it completed, and it is never rescheduled after reaching a terminal no-change outcome. A Campaign whose Tasks are all `succeeded_no_change` or `skipped` becomes ready for human acceptance with `completionOutcome=already_satisfied`.

package/docs/architecture/current/failure-recovery.md

@@ -440,30 +440,6 @@ The Gateway does not infer execution failure from a disconnected request. Caller
 - repository A recovery does not require locking repository B;
 - bounded projections remain readable while Workers execute.
 
-## Campaign Recovery
-
-Campaign state survives Gateway, MCP, ChatGPT, scheduler, and worker restarts. Reconciliation treats persisted Execution Jobs and Agent Runs as the execution source of truth. Missing, orphaned, timed-out, or human-attention child work becomes a bounded Campaign task failure and may open a Supervisor Checkpoint.
-
-No in-memory ChatGPT conversation is required for recovery. Duplicate review delivery and scheduler delivery are idempotent. A stale checkpoint nonce, stale goal revision, or conflicting request-ID reuse is rejected rather than replayed against newer state.
-
-### Campaign checkout recovery
-
-Campaign worktree identity is stored in Controller Home with its request id, branch, path, and original base revision. Repeated creation reuses this manifest and registered checkout even if the source checkout advances. A missing directory is reconstructed from the retained branch after stale Git worktree metadata is pruned.
-
-## 25. Campaign Cancellation Finalizer
-
-Campaign cancellation is a two-phase state transition:
-
-```text
-active / paused / waiting_for_supervisor
-  -> cancelling
-  -> cancelled | cancelled_with_leaks
-```
-
-Entering `cancelling` blocks new Task dispatch, supersedes open checkpoints, and marks non-terminal Tasks cancelled. The finalizer then cancels Task and Supervisor Execution Jobs, which terminate owned process trees and release Leases. A managed Campaign worktree is removed only when its path and branch identity match and the workspace is clean. Unknown, dirty, or committed resources are preserved and reported as leaks.
-
-`cancelled` is written only after the cleanup report is durable. Cleanup is idempotent; a Campaign in `cancelled_with_leaks` may be reconciled again after an operator resolves the preserved resource.
-
 ## 26. Runtime Storage Recovery
 
 Every Controller Home runtime directory carries a repository/binding owner marker. Empty or terminal legacy storage is migrated and replaced with a repository-local link. Non-conflicting entries are merged. Name collisions are moved to a repository-scoped quarantine with a diagnostic path rather than overwritten or deleted.

package/docs/architecture/current/governance.md

@@ -109,7 +109,7 @@ rule
 observed implementation
 risk
 temporary behavior
-owner Issue/Task
+owner Requirement/Work item or ADR
 target closure condition
 verification
 ```

package/docs/architecture/current/implementation-status.md

@@ -62,7 +62,7 @@ The normal ChatGPT-facing MCP surface is a bounded **19-tool** schema. The five
 
 The Runtime keeps internal atomic handlers and an exhaustive `full` compatibility profile without advertising them to ordinary ChatGPT discovery. `core` remains a compatibility label for the same bounded default surface. Request/Full Access changes execution authorization, not tool discovery.
 
-Small understood work is Direct-first. Repository commands and checks use Unified Process Runtime and return one stable Process lifecycle; known-long calls can return a handle immediately, while later `process_get`, `process_wait`, `process_logs`, and `process_cancel` attach to that same physical execution. Durable Work, isolated worktrees, workers, or campaigns are introduced when recovery, dependency tracking, isolation, parallelism, or a longer lifecycle actually requires them.
+Small understood work is Direct-first. Repository commands and checks use Unified Process Runtime and return one stable Process lifecycle; known-long calls can return a handle immediately, while later `process_get`, `process_wait`, `process_logs`, and `process_cancel` attach to that same physical execution. Durable Work, isolated worktrees, or workers are introduced when recovery, dependency tracking, isolation, parallelism, or a longer lifecycle actually requires them.
 
 Tool names and input schemas are fingerprinted. A stale MCP session receives `MCP_TOOL_SURFACE_CHANGED` with a reinitialize instruction while its transport remains available for the host to observe the reset. Replacement initialize then supersedes and closes the old session; schema rotation must not unregister the Forge namespace from the host conversation.
 

package/docs/architecture/current/legacy-governance.md

@@ -0,0 +1,58 @@
+# Legacy Capability Governance
+
+> Status: **Runtime Authority**
+
+Forge is a direct descendant of RepoHarness. Provenance is historical fact, not a runtime compatibility requirement. Governance removes obsolete authorities and duplicate entrypoints while retaining implementations that still satisfy current invariants.
+
+## Rule
+
+A capability may survive from RepoHarness when it has one current owner, does not create a second lifecycle writer, and does not require an external Agent/skill for correctness. Code should be rewritten only when the old implementation violates those invariants; lineage alone is not a reason to rewrite working code.
+
+## Capability disposition
+
+| Capability | Disposition | Current authority |
+|---|---|---|
+| Plan/spec source artifacts | keep | Git source artifacts; Runtime Plan/Work owns migrated lifecycle state |
+| Contract/check/review evidence | keep and bound | Git/evidence plane; completion policy evaluates evidence |
+| Repository/process/worktree execution | replace legacy orchestration | Canonical Runtime, Process Runtime, Resource Claims/Leases |
+| CodeGraph | internalize | `rh_context` + bundled structural backend; host MCP is optional |
+| Hook adapters | keep thin | host event adapter only; never lifecycle owner |
+| Session resume context | rename/demote | `.ai/harness/session/*` rebuildable cache only |
+| Decision handoff | keep as Runtime object | `HandoffItem` surfaced through `rh_inbox` |
+| Browser human-interaction handoff | keep separate | browser interaction policy; not Work/Plan handoff |
+| Waza/gstack/gbrain/Mermaid | optional | external host enhancement only |
+| Campaign | remove | no current authority |
+| legacy Issue/Task/project writers | freeze/remove | migrated Requirement/Plan/Work state in SQLite |
+| legacy helper/host commands | hide then delete when no managed callers remain | public CLI exposes product workflows only |
+
+## Handoff terminology
+
+Three historical concepts used the same word and must remain separated:
+
+1. **Runtime HandoffItem** — a durable decision/attention item created for ambiguity, authorization, repeated infrastructure failure, or human review. This is the only generic Forge object called a handoff.
+2. **Session continuation cache** — ignored Markdown under `.ai/harness/session/` used to rehydrate a fresh Codex/Claude session. It is derived, rebuildable, and cannot approve work or override Runtime state.
+3. **Browser human-interaction handoff** — a bounded browser/UI interaction that needs a human (for example login/CAPTCHA). It is an interaction-plane event, not a repository lifecycle state.
+
+Hooks may refresh (2). Hooks must never synthesize or resolve (1) by writing Markdown.
+
+## CLI governance
+
+Public top-level commands should describe user goals, not implementation layers.
+
+Public: `install`, `update`, `adopt`, `uninstall`, `setup`, `status`, `doctor`, `repo`, `runtime`, `recovery`, `plugin`, `chatgpt`, `mcp`, `tools`, `security`, `docs`.
+
+Hidden compatibility/host machinery may remain callable while generated workflows still use it: `hook`, `run`, legacy `controller`, `migrate`, `brain`, `capability-context`, and `prompt-guard-decide`.
+
+`init` and `init-hook` are retired duplicate public entrypoints. Use `install` and `setup check` respectively.
+
+## Removal policy
+
+A hidden compatibility surface can be deleted when:
+
+1. no current generated asset writes or documents it as a primary route;
+2. no current Runtime/host adapter invokes it;
+3. migration/readback coverage proves old persisted state has an explicit replacement or is intentionally abandoned;
+4. focused tests and architecture checks prove the replacement path;
+5. deletion does not recreate the capability under a new duplicate abstraction.
+
+Historical Git commits, changelog entries, ADRs, and third-party notices are not rewritten merely to erase RepoHarness provenance.

package/docs/architecture/current/multi-repository-execution.md

@@ -23,7 +23,7 @@ checkoutId when applicable
 
 A repository has independent:
 
-- Issue and Task state;
+- Requirement and Work state;
 - Jobs and Runs;
 - Claims and Leases;
 - Workspaces and Worktrees;

package/docs/architecture/current/peer-supercontroller-runtime.md

@@ -20,7 +20,7 @@ Status: active on `codex/supercontroller-refactor`
 ## Semantic / external paths
 
 - Non-deterministic schedules record occurrence + Handoff only
-- Campaign reconcile migrates unfinished tasks into Work + Handoff
+- Long-lived work persists as Work + Handoff and can be resumed by an external SuperController
 - Legacy Agent dispatch tools return structured retirement responses
 
 ## Failure policy

package/docs/architecture/current/personal-assistant-plugin-baseline.md

@@ -18,7 +18,7 @@ Current implementation:
   adapters under `src/runtime/plugins/`, all surfaced through Controller CLI,
   Local Bridge APIs, and MCP compatibility tools.
 - ChatGPT browser automation exists under `src/cli/chatgpt-browser/` and the
-  campaign/runtime control plane. It is an execution channel, not a plugin
+  runtime control plane. It is an execution channel, not a plugin
   registry entry.
 - Calendar support exists both as a runtime Schedule trigger under
   `src/runtime/workflow/schedules/` and as a separate Google Calendar account
@@ -43,7 +43,7 @@ Compatibility rule:
 ChatGPT / Local UI / CLI
   -> MCP Gateway + Local Bridge
      -> Controller Runtime
-        -> durable Jobs / campaigns / schedules / evidence
+        -> durable Jobs / Goal/Work / schedules / evidence
            -> optional provider adapters
               -> GitHub plugin (implemented)
               -> Gmail adapter (implemented)
@@ -61,9 +61,8 @@ operations on top of that runtime, not as a second orchestrator.
 
 | Capability | Source of truth | Persistence and boundary | External side effect | Status |
 | --- | --- | --- | --- | --- |
-| GitHub Issue/Project sync | `src/cli/github/plugin.ts`, `src/cli/commands/controller.ts`, `src/cli/local-bridge/server.ts` | `.Forge/plugins/github.json` plus repository registry mapping | GitHub issue/project mutation | Implemented |
+| GitHub Issue/Project sync | `src/cli/github/plugin.ts`, `src/cli/local-bridge/server.ts` | `.Forge/plugins/github.json` plus repository registry mapping | GitHub issue/project mutation | Implemented |
 | Durable assistant work submission | `src/runtime/gateway/mcp/runtime-tools.ts`, `src/runtime/execution/jobs/` | Controller Home `execution-jobs/`, events, artifacts, projections | Repository-local work and approved provider actions | Implemented |
-| ChatGPT-supervised campaigns | `src/runtime/workflow/campaigns/`, `src/cli/chatgpt-browser/` | Campaign records, review packets, workspaces, evidence | Browser-visible ChatGPT session or delegated local work | Implemented and opt-in |
 | Calendar time-based triggering | `src/runtime/workflow/schedules/store.ts`, `engine.ts` | Schedule, Decision, Occurrence records | Launches bounded runtime Jobs only | Implemented |
 | Calendar account read/write | `src/runtime/plugins/google-calendar-adapter.ts` | `.Forge/plugins/google-calendar.json`, derived manifest/index, env-only credentials | Google Calendar event read/write | Implemented |
 | Gmail mailbox read/write | `src/runtime/plugins/gmail-adapter.ts` | `.Forge/plugins/gmail.json`, derived manifest/index, env-only credentials | Gmail read/send/trash | Implemented |
@@ -155,7 +154,7 @@ Current implementation:
 
 The current source-aligned assistant baseline is:
 
-- Controller Runtime plus durable Jobs/campaigns/schedules are the assistant
+- Controller Runtime plus durable Jobs/Goal/Work/schedules are the assistant
   execution substrate.
 - GitHub, Gmail, Google Calendar, and Google Tasks are implemented persisted
   plugin adapters behind the generic plugin runtime contract.

package/docs/architecture/current/scheduler-and-resource-claims.md

@@ -420,13 +420,3 @@ The runtime now implements:
 - owner-bound Worker heartbeat, Lease renewal, release and terminal writes.
 
 New concurrency features must express their resources through this model. Additional ad-hoc long-lived locks require an ADR and may not execute on the Gateway event loop.
-
-## Campaign Scheduling
-
-The global scheduler runs bounded Campaign reconciliation outside the global dispatch reservation lock. Campaigns use one short lock per Campaign identity, while child Jobs continue to use normal resource claims and fencing tokens. This prevents one slow review or failed task from serializing unrelated Campaigns or repositories.
-
-Agent Campaign tasks are normalized to `isolate: true` and therefore claim a task worktree rather than the active production workspace. Waiting Checkpoints carry no lease. Retry timestamps are durable and include bounded backoff and jitter to avoid retry storms.
-
-### Campaign creation claims
-
-`create_campaign` briefly claims repository state and `git-refs:<repoId>` while creating or recovering the deterministic Campaign worktree. Normal Campaign reconciliation uses short per-Campaign locks. Supervisor triggers claim no repository resource, and implementation Jobs claim the Campaign checkout or a task-specific child worktree.

package/docs/architecture/current/target-requirements-traceability.md

@@ -60,7 +60,7 @@ Verification: `tests/runtime/canonical-single-runtime.test.ts`, `scripts/smoke-m
 
 ## 5. Work-mode and Agent strategy
 
-The original Direct Edit, Quick Agent and Issue/Task assessment remains available. Runtime dispatch persists the chosen operation and preserves allowed Agent providers, timeout and browser permissions. Explorer/Implementer/Verifier policy remains a planning concern; deterministic integration and release checks remain program-owned rather than LLM-owned.
+Direct Edit and Quick Agent remain available; historical Issue/Task assessment is compatibility/read-only after Requirement/Work cutover. Runtime dispatch persists the chosen operation and preserves allowed Agent providers, timeout and browser permissions. Explorer/Implementer/Verifier policy remains a planning concern; deterministic integration and release checks remain program-owned rather than LLM-owned.
 
 Evidence: `src/cli/controller/work-mode.ts`, `src/runtime/gateway/mcp/router.ts`, `src/runtime/execution/workers/executor.ts`.
 
@@ -185,7 +185,7 @@ Detailed evidence: [`migration-roadmap.md`](migration-roadmap.md).
 Resolve Repository
 -> read compact projection
 -> classify work mode
--> select/create Issue and Task when required
+-> select/create Requirement and Work when required
 -> declare Scope and Claims
 -> persist requestId and ExecutionJob
 -> return Job ID

package/docs/architecture/current/thin-harness-governance-policy.md

@@ -13,7 +13,7 @@ Priority order:
 1. Direct edit
 2. Requirement/workflow
 3. Issue/task orchestration
-4. Campaign
+4. Durable Goal Workloop / PlanContract coordination
 
 ## Architecture strategy changes
 

package/docs/architecture/current/thin-harness-v1.md

@@ -14,7 +14,7 @@ Core principle:
 Default to direct Fast Path execution.
 Escalate to Durable Work only when recovery, background, isolation,
 concurrent writes, or high-risk control is required.
-Use Campaign only for multiple truly independent, long-lived deliverables.
+Use durable Goal Workloop plus PlanContract/Work only when multiple independent, long-lived deliverables need resumable coordination.
 ```
 
 ## Current Implementation
@@ -53,11 +53,11 @@ interface ExecutionDecision {
 
 The sole Route Policy exposes three task-shape tiers. These are routing labels over existing execution primitives, not separate engines:
 
-1. **Direct** — `direct_edit` + `direct_control` + `fast`. Use for small, scope-clear, low-risk work. Readonly work creates no Work; small mutations may retain lightweight Work lineage without Issue, Plan, Campaign, or isolated worktree by default.
+1. **Direct** — `direct_edit` + `direct_control` + `fast`. Use for small, scope-clear, low-risk work. Readonly work creates no Work; small mutations may retain lightweight Work lineage without Issue, Plan, or isolated worktree by default.
 2. **Bounded Work** — `bounded_work` + `goal_workloop` + `durable`. Use for one-owner work that needs investigation, recovery, isolation, protected-path handling, or broader bounded scope. It uses the existing WorkContract / `rh_work` lifecycle and does **not** require an Issue or Plan.
-3. **Campaign** — `campaign` + `goal_workloop` + `campaign`. Use only when the task explicitly contains multiple independent deliverables or parallel independent tasks that need coordination. Campaign selection is based on task topology, not on whether an Agent/provider was requested.
+3. **Coordinated durable Work** — `bounded_work` + `goal_workloop` + `durable`. Use when multiple independent deliverables need resumable coordination; decompose them with PlanContract/Work instead of a separate project-level lifecycle.
 
-`quick_agent` and `issue_task` remain executor/delegation-oriented modes when an Agent is explicitly requested and Campaign topology is absent. Provider choice never promotes a small task into Campaign by itself. An explicit approved Plan may still bind dependent Work steps, but Plan is optional and is never a prerequisite for Bounded Work or Campaign routing.
+`quick_agent` and `issue_task` remain executor/delegation-oriented modes when an Agent is explicitly requested. Provider choice never promotes a small task into a heavier lifecycle by itself. An explicit approved Plan may bind dependent Work steps, but Plan is optional for ordinary Bounded Work.
 
 ### Fast Path eligibility (default)
 
@@ -141,7 +141,6 @@ For short **typed-argv** readonly repository commands, the bounded direct reader
 - Local Job
 - Scheduler record
 - Worker process
-- Campaign state
 - Issue Task
 - Project Board records
 - full projection rebuild per step
@@ -252,7 +251,7 @@ Rules:
 ### Read-only Analysis Lane
 
 - max concurrency 4
-- shared checkout, no branch / worktree / Issue / Campaign
+- shared checkout, no branch / worktree / Issue
 - parent receipt only; child lanes use `receiptMode: none`
 - real overlap via async primitives; `concurrent` flag reports start/finish overlap
 - fail-fast optional (default continue)
@@ -264,12 +263,11 @@ Rules:
 - never writes the main checkout
 - Integrator rechecks revision, conflicts, writePaths subset, digests before apply
 
-## Campaign boundary
+## Durable coordination boundary
 
-- Fast Path never depends on Campaign
-- Campaign remains **opt-in** long orchestration
-- ordinary Direct Edit must not auto-upgrade to Campaign
-- this slice does **not** rewrite Campaign completion, merge, cleanup, or workspace models
+- Fast Path never depends on a project-level orchestration lifecycle.
+- Independent deliverables use Goal Workloop plus PlanContract/Work only when durable coordination is needed.
+- ordinary Direct Edit must not auto-upgrade merely because parallel analysis is possible.
 
 ## Latency measurement
 

package/docs/architecture/domains/runtime-harness.md

@@ -19,7 +19,7 @@ instead of becoming separate hook sources of truth.
 - User-level `~/.claude/settings.json` and `~/.codex/hooks.json` are the host adapter surfaces.
 - Repo-local `.claude/settings.json` and `.codex/hooks.json` hook adapters are retired legacy config, not required contract files.
 - Other repo-local `.codex/*` files are runtime residue unless promoted by an explicit contract change.
-- Runtime files under `.ai/harness/checks`, `.ai/harness/handoff`, `.ai/harness/failures`, `.ai/harness/architecture/events.jsonl`, `.ai/harness/worktrees`, and `.ai/harness/runs` are ignored state, not durable deliverables.
+- Runtime files under `.ai/harness/checks`, `.ai/harness/session`, `.ai/harness/controller/packets`, `.ai/harness/projections`, `.ai/harness/transfers`, `.ai/harness/failures`, `.ai/harness/architecture/events.jsonl`, `.ai/harness/worktrees`, and `.ai/harness/runs` are ignored state, not durable deliverables.
 
 ## Verification Surface
 

package/docs/forge-autonomous-goal-loop.md

@@ -2,6 +2,8 @@
 
 Forge supports bounded goal progression through durable Goal, Work, Process, evidence, policy, and handoff records. The kernel does not recursively invent unlimited work, select arbitrary models, or bypass authorization. Semantic planning and provider selection belong to the external controller; deterministic repository and provider operations remain Forge-owned.
 
-Every continuation must have a finite objective, resource scope, budget, stop condition, and reviewable evidence. Remote or destructive effects stay separately authorized.
+Every continuation must have a finite objective, resource scope, budget, stop condition, and reviewable evidence. Remote or destructive effects stay separately authorized. A Schedule can wake an external Controller for an existing bounded Work; ChatGPT wakeups reuse a saved Forge browser session or explicit conversation URL when available, so conversation continuity is a transport concern rather than Kernel reasoning.
+The stable configuration path is `rh_work.schedule_*`: create one continuation policy for an already accepted Work, inspect it, pause/resume it, or trigger one bounded Occurrence. The engine re-checks Work terminality before launch and automatically disables the Schedule when the Work is complete, so users do not need to keep sending “continue” and Forge does not keep waking a model after acceptance is satisfied.
+A scheduled wake uses a short launch reservation rather than a fake Controller lease. The external model becomes owner only after its own authenticated MCP session calls `rh_work continue`; this is the identity handoff boundary between deterministic scheduling and semantic control.
 
 See [Dispatch and Agent Strategy](architecture/current/dispatch-and-agent-strategy.md), [Schedule Engine](architecture/current/automation-and-schedule-engine.md), and [Governance](architecture/current/governance.md).