@moretea-labs/forge 1.8.1 → 1.8.2

package/supervisor/types.ts

@@ -1,8 +1,7 @@
-export type WorkflowSupervisorAction = 'CONTINUE' | 'DONE' | 'NEEDS_USER';
-export type WorkflowSupervisorState = 'running' | 'done' | 'needs_user';
+export type WorkflowSupervisorAction = 'CONTINUE' | 'WAIT' | 'DONE' | 'NEEDS_USER';
+export type WorkflowSupervisorState = 'running' | 'waiting' | 'done' | 'needs_user';
 export type WorkflowSupervisorTerminalState = 'DONE' | 'NEEDS_USER' | 'STOPPED';
 /** Machine receipt attached to Forge MCP calls made by an autonomous ChatGPT turn. */
-export type WorkflowSupervisorAutomationStatus = 'working' | 'continue' | 'done' | 'needs_user';
 export type WorkflowEffectKind = 'enrollment' | 'continuation' | 'correction' | 'recovery';
 export type WorkflowEffectOutcome = 'applied' | 'not_applied' | 'unknown';
 
@@ -32,12 +31,8 @@ export interface WorkflowSupervisorTurnEnvelope {
     role: 'advisory';
     projection: string;
   };
-  automation: {
-    automation_task_id: string;
-    automation_type: 'autonomous_continuation';
-    intermediate_status: 'working';
-    final_statuses: ['continue', 'done', 'needs_user'];
-  };
+  /** Final assistant reply receipt. No intermediate MCP call can end a turn. */
+  receipt: { challenge: string };
 }
 
 export interface WorkflowSupervisorProposal {
@@ -95,9 +90,9 @@ export interface WorkflowSupervisorContinuationProof {
   taskId: string;
   conversationId: string;
   activeReleaseId: string;
-  actions: ['CONTINUE', 'CONTINUE'];
-  completionFingerprints: [string, string];
-  sourceEffectIds: [string, string];
+  actions: ['CONTINUE', 'CONTINUE', 'DONE'];
+  completionFingerprints: [string, string, string];
+  sourceEffectIds: [string, string, string];
   runtimeInstanceIds: string[];
   firstCommittedAt: string;
   lastCommittedAt: string;
@@ -144,12 +139,21 @@ export interface WorkflowContractValidation {
  * delivery queue with no durable projection; this makes that state visible and
  * names the exact operator action that can move the task forward.
  */
+export interface WorkflowSupervisorPreflightComposerObservation {
+  /** Diagnostic of the existing editor before Send, never a draft writer or replay authority. */
+  chars: number;
+  fingerprint: string;
+  classification: 'empty' | 'current_effect' | 'other_effect' | 'unattributed' | 'unavailable';
+  selectorVersion?: string;
+}
+
 export type WorkflowSupervisorTaskStall =
   | { state: 'terminal' }
   | { state: 'deliverable'; effectId: string; mode: 'send' | 'reconcile'; generation: number }
-  | { state: 'spaced'; effectId?: string; reason: 'retry_spacing' | 'unknown_observation_spacing' | 'awaiting_completion_receipt' | 'pre_send_infrastructure_blocked' }
+  | { state: 'spaced'; effectId?: string; reason: 'retry_spacing' | 'unknown_observation_spacing' | 'awaiting_completion_receipt' | 'pre_send_infrastructure_blocked'; preflightReasonCode?: string; preflightComposerObservation?: WorkflowSupervisorPreflightComposerObservation }
   | { state: 'retryable'; effectId: string; generations: number; maxGenerations: number }
   | { state: 'provider_resume_exhausted'; effectId: string }
+  | { state: 'waiting'; scheduleId: string; completionFingerprint: string }
   | { state: 'inert' };
 
 export interface WorkflowSupervisorValidators {
@@ -165,6 +169,8 @@ export interface WorkflowSupervisorLifecycleHooks {
   projectScopeForTask?(task: WorkflowSupervisorTask): WorkflowSupervisorProjectScope | undefined;
   /** Build the one bounded enrollment task for a newly discovered project conversation. */
   discoveredConversationTask?(conversation: WorkflowSupervisorDiscoveredConversation, scope: WorkflowSupervisorProjectScope): WorkflowSupervisorTaskInput | undefined;
+  /** Exact Work-owned terminal transition, projected into the one Supervisor stop-event writer. */
+  terminalWorkStopReasonForTask?(task: WorkflowSupervisorTask): string | undefined;
   /** Admission for a new send only. Never suppress observation of an already-started effect. */
   browserTaskActive?(task: WorkflowSupervisorTask): boolean;
   /** Mechanical provenance attached to outbound effect dispatch evidence. */

package/SKILL.md

@@ -1,427 +0,0 @@
----
-name: forge
-description: Single canonical skill for operating forge CLI, controller, hooks, planning, repair, verification, and delivery workflows
-when_to_use: "forge, initialize repo-local agentic development harness, scaffold new project with forge, migrate repo-local agentic development harness, audit repo-local agentic development harness, repair repo-local agentic development harness"
----
-
-# Forge
-
-Forge is the CLI, Runtime, and hook automation product for repo-local agentic development. This skill is the single host-discoverable router for the versioned workflow engine and CLI commands.
-
-Product boundary:
-
-- internal engine: CLI plus hook-backed tasks-first harness
-- contract ID: tasks-first-harness-v1
-- canonical skill, CLI, and package name: `forge`
-- new-project creation surface: `forge scaffold`
-
-Retired project-skill and project-initializer staging paths are not recognized, synchronized, or cleaned up by current tooling. Historical markers in long-migrated repositories are inert evidence.
-
-The skill should not carry the whole workflow contract in prose. It should:
-
-1. inspect the repository
-2. classify the workflow state
-3. choose the correct path
-4. rely on the repo contract, migration scripts, and tests for enforcement
-
-## Forge execution runtime
-
-Treat ChatGPT as the controller and Forge as its repository execution layer. ChatGPT chooses how to inspect, plan, edit, verify, or delegate. Forge provides deterministic repository tools and does not impose an Agent-first workflow.
-
-- Direct Edit is the default for understood work. One session may accept many patch batches, keep revision history, create savepoints, run checks, roll back selected revisions, and finalize one aggregate localized diff.
-- Tasks describe objectives, scope, checks, and acceptance criteria. They do not permanently bind Codex, Claude, or GitHub Copilot. The executor is selected when each Run starts.
-- Agents are optional implementation tools for broad exploration, large refactors, or compile/test/fix loops. They receive a high-level implementation contract; ChatGPT still reviews the result and decides what happens next.
-- Ordinary local risk levels are metadata, not permission gates. There is no approval queue and no `approve_risk` handshake. Only an explicitly destructive or irreversible operation requires authorization in the same request.
-- The Controller UI is hierarchical: Overview, Work, Activity, and Settings. Work is organized as Issue -> Task -> Execution instead of exposing every technical record as a top-level destination.
-- Hard runtime boundaries remain for secrets, credentials, Git internals, concurrent write conflicts, out-of-scope writes when a scope is declared, and remote or irreversible side effects.
-## Explicit mode directives
-
-Automatic routing remains authoritative when the user does not provide a mode directive. In particular, understood bounded work still defaults to Direct Edit; adding explicit modes must not make ordinary requests Plan-first, Agent-first, Issue-first.
-
-A leading mode directive is an opt-in instruction to ChatGPT's Forge router. It applies only to the current request, is removed from the objective before execution, and never bypasses permissions, Runtime authority, protected-path rules, approvals, or destructive/remote-write confirmation.
-
-- `-plan` or `/plan`: force the reviewed planning path. Planning is read-only: inspect repository state and call `rh_context` search with `structural_context=required` so CodeGraph symbol/reference/dependency/impact evidence is used when the index is ready; load only relevant architecture/ADR/design/README material, then create or revise the existing PlanContract. Review the PlanContract before approval. Do not start mutation until the reviewed plan is approved and execution is explicitly bound to an approved plan step. If CodeGraph is unavailable or stale, keep the degraded evidence warning visible and use bounded current-source context instead of pretending graph coverage exists.
-- `-debug` or `/debug`: force evidence-first debugging. Reproduce or characterize the failure, then prefer repeated `rh_context` search with `structural_context=auto` to isolate callers, dependencies, and the smallest causal surface before patching and focused verification. The directive does not force an Agent or durable Work; existing routing still chooses Direct, bounded Work, or an optional worker from the actual scope and risk.
-
-A bare directive with no objective should return/explain that mode's working contract and must not mutate repository state. Mode directives are not sticky across turns unless the user repeats them or explicitly asks to continue the same active Plan/Work.
-
-## When to use
-
-- install or refresh the CLI+hooks workflow in an existing repo
-- create a new project or module scaffold only when the user asks for a new product/module skeleton, then attach the harness
-- migrate an older repo to the current tasks-first harness
-- audit drift between prompts, hooks, scripts, and repo-local contract files
-- repair broken task-sync, workflow-contract, or handoff surfaces
-
-## When not to use
-
-- runtime bug debugging inside an already healthy AI workflow
-- generic project scaffolding unrelated to AI routing or repo-local workflow contracts
-- using scaffold to adopt an existing repo; choose the canonical router's init,
-  migrate, upgrade, or repair path instead
-- ordinary product feature work
-
-## Controller direct-change rule
-
-When this skill is used to operate the Controller itself, prefer a bounded direct edit for known small documentation, configuration, or code changes. The expected chain is `read_repository_file -> begin_edit_session -> apply_patch -> get_edit_session_diff -> verify_edit_session -> finalize_edit_session`. Create an Issue only when investigation, dependencies, broad scope, parallelism, long-running verification, or elevated risk requires durable orchestration. Issue creation alone is never a completed result.
-
-## Router Protocol
-
-Always start with structured inspection, not prompt guessing.
-
-### Step 1. Inspect first
-
-Run:
-
-- `bun scripts/inspect-project-state.ts --repo <path> --format text`
-  - fallback: `node --loader ./src/runtime/shared/node-ts-loader.mjs scripts/inspect-project-state.ts --repo <path> --format text`
-
-Read the result fields:
-
-- `mode`
-- `legacy_contract_version`
-- `drift_signals`
-- `required_decisions`
-- `safe_defaults`
-
-### Step 2. Choose one path
-
-Classify the request into one canonical workflow path before running checks or
-edits. The CLI subcommands are execution surfaces, not separate skills. For
-example, pre-merge or release readiness uses the check path, while broken task
-sync, hook routing, handoff, context, policy, or helper surfaces use repair.
-
-1. **Scaffold**
-   - use only when creating a new project, app, or module skeleton
-   - use `forge scaffold`
-   - choose the A-K project catalog entry, then optional `ai_native_profile`
-   - attach the harness after the project structure exists
-   - do not use this path for existing-repo adoption
-2. **Initialize**
-   - use when the repo has no meaningful tasks-first workflow yet
-3. **Migrate**
-   - use when the repo has legacy workflow docs, missing contract manifest, or stale harness artifacts
-4. **Audit**
-   - use when the repo mostly works but the user wants drift analysis and enforcement review
-5. **Repair**
-   - use when the repo has a current contract surface but broken task-sync, hooks, or handoff behavior
-### Step 3. Prefer engine actions over prompt-only fixes
-
-Default order:
-
-1. for new projects, scaffold the requested project/module shape first
-2. migrate legacy docs if needed
-3. install or refresh workflow contract artifacts
-4. sync hooks, helpers, and templates
-5. merge the guidance-only `external_tooling` profile into `.ai/harness/policy.json`
-6. verify the repo-local contract
-
-Do not treat hooks as the primary source of truth. The repo contract lives in repo files.
-
-## Core Engine Surfaces
-
-The single machine-readable contract source is:
-
-- `assets/workflow-contract.v1.json`
-
-The installed runtime copy inside a repo is:
-
-- `.ai/harness/workflow-contract.json`
-
-The main engine entrypoints are:
-
-- `scripts/inspect-project-state.ts`
-- `scripts/migrate-workflow-docs.ts`
-- `scripts/migrate-project-template.sh`
-- `scripts/check-agent-tooling.sh`
-- `scripts/check-task-workflow.sh`
-- `scripts/create-project-dirs.sh`
-
-## CLI Workflow Surface
-
-`forge` is the only host-discoverable skill. Planning, review, execution,
-maintenance, verification, delivery, browser consultation, and setup remain CLI
-commands or controller capabilities selected by this router. Do not install one
-skill per command.
-
-Choose the smallest applicable path:
-
-- planning: plan, PRD, review, sprint, or bounded goal preparation
-- lifecycle: init, scaffold, migrate, upgrade, or capability configuration
-- maintenance: architecture, deploy-readiness, handoff, repair, or check
-- execution and delivery: direct controller work, automated workflow, or ship
-- consultation: ChatGPT browser/GPT Pro setup and consult commands, preserving
-  the existing credential, session, and user-consent boundaries
-
-The implementation authority remains in the CLI, controller tools, scripts,
-hooks, and versioned contract files. Add a separate skill only when it represents
-a genuinely independent knowledge domain with a non-overlapping trigger and
-safety model; a CLI alias is not sufficient justification.
-
-## Plan Index
-
-Keep A-K as stable scaffold codes, but route them as stack-family handles, not
-product prescriptions. Choose by frontend shell, backend/runtime boundary,
-deployment target, data authority, and sidecar needs first. Product domains
-such as finance, CRM, Web3, healthcare, and commerce are overlays.
-
-Core Plans (A-F), routed as stack families:
-- Plan A: Astro-first SSR/content shell. Use Astro for SSR, content, docs,
-  marketing, and mostly-static app shells with islands where needed.
-- Plan B: Vite 8 client-only app shell. Use Vite + React + TanStack
-  Router/Query plus shadcn/Radix-style UI for dense interactive apps and
-  internal tools that do not need crawler-visible SSR landing HTML.
-- Plan C: TanStack Start Workers webapp. Prefer TanStack Start + Vite +
-  Cloudflare Workers when the same React webapp needs public SEO/SSR at `/`
-  and authenticated or browser-heavy workspace routes under `/app`. Use
-  route-level `ssr: false` for `/app`; Next.js is not a default recommendation.
-- Plan D: Shared frontend/backend monorepo. Prefer Bun workspaces with apps,
-  packages, shared contracts, a Hono gateway, and optional Turborepo only when
-  repo scale needs orchestration.
-- Plan E: Cloudflare edge web stack. Prefer Workers for TanStack Start SSR
-  webapps, Pages only for static/client-only assets or content shells, and R2,
-  KV, Queues, Durable Objects, and Hyperdrive where they fit. Do not default to
-  D1; use Postgres/Supabase or SQLite/Turso unless the D1 tradeoff is explicit.
-- Plan F: Mobile/realtime companion. Use Expo Router on React Native New
-  Architecture, with NativeWind where useful and explicit voice/media/realtime
-  boundaries when needed.
-
-Custom Presets (G-K), routed as sidecar/runtime families:
-- Plan G: Python research/data/agent sidecar. Use `uv`, FastAPI or Pydantic AI,
-  DuckDB/Polars, evals, and artifact storage behind the app gateway.
-- Plan H: Go high-concurrency or financial sidecar. Use Go/Gin or narrow Go
-  workers for market data, FIX/RFQ, fan-out, infra adapters, and TS-adjacent
-  high-concurrency services.
-- Plan I: Local-first or lightweight SQL stack. Use SQLite, Turso/libSQL,
-  Turso Sync for new local-first sync work, Loro or other sync primitives, and
-  explicit replication/ownership contracts.
-- Plan J: Rust native/performance sidecar. Use Rust for parsers, indexing,
-  sandboxing, native kernels, and low-latency tools when the team can support
-  the operational complexity.
-- Plan K: Fully custom configuration. Use when the stack cannot be expressed as
-  a composition of the families above.
-
-Agent runtimes that need stable Node APIs, long-lived processes, local tools,
-or heavier sidecars should default to VPS deployment behind the Hono gateway,
-not Cloudflare Workers. Cloudflare remains the preferred web/edge delivery
-surface, not the mandatory agent execution environment.
-
-## AI-native scaffold overlay
-
-`forge scaffold` keeps A-K as the stack-family catalog and uses
-`ai_native_profile` as a separate overlay axis. The default profile is `none`,
-so generated output stays on the selected family unless the user asks for agentic
-runtime behavior. Use an overlay only when the generated app needs agent UI,
-streaming protocol, tool boundary, sidecar, shared state, approvals, artifacts,
-or observability.
-
-Supported profile IDs live in `assets/initializer-question-pack.v4.json`.
-Current stack guidance:
-
-- Use Astro for SSR/content/docs shells and Vite 8 for rich interactive
-  surfaces. Prefer a shared monorepo over disconnected frontend/backend repos.
-- Use TanStack Start + Vite + Cloudflare Workers when a SaaS webapp needs
-  public landing SEO/SSR and a client-heavy workspace in the same product
-  surface. Keep `/` SSR/prerender-capable and `/app` client-only.
-- Do not scaffold `apps/marketing` plus `apps/web` as the default answer to
-  SEO/SSR. Treat a static marketing app as explicit legacy/rollback or content
-  scope, not as the normal SaaS webapp split.
-- Use React Router Framework Mode or Vike only as fallback evaluations if the
-  Start + Workers thin scaffold gate fails. Do not default to Next.js.
-- Use Expo Router for mobile and keep React Native New Architecture
-  compatibility visible in the scaffold.
-- Use assistant-ui or AI SDK UI for chat and generative UI primitives; use
-  AG-UI when the frontend and backend need a durable event stream for runs,
-  tools, shared state, interrupts, approvals, replay, or multimodal updates.
-- Use Bun/Hono as the default app-facing agent gateway. The gateway owns auth,
-  policy, run IDs, tool contracts, approval state, streaming, and telemetry
-  before any model framework or sidecar runs.
-- Prefer Cloudflare for web and edge delivery, but keep agent runtimes on VPS
-  when they need Node compatibility, local tools, long-lived workers, or heavier
-  sidecars. D1 is opt-in, not the default database.
-- Use MCP or narrow HTTP jobs for tools and sidecars. Do not let MCP servers,
-  model providers, or agent frameworks become product authority.
-- Keep orchestration swappable: AI SDK for simple provider/tool streaming;
-  OpenAI Agents SDK, Mastra, LangGraph, Pydantic AI, or a custom runner only
-  when the product needs multi-step state, handoffs, memory, evals, approvals,
-  or durable execution.
-- Prefer Postgres or Supabase for durable app authority. Use SQLite or
-  Turso/libSQL for lightweight, local-first, edge, or embedded workloads.
-  Treat object storage, queues, Redis, vector stores, ClickHouse,
-  Temporal/Inngest/BullMQ/Trigger.dev, and OpenTelemetry as opt-in capability
-  boundaries, not mandatory scaffold defaults.
-
-Generated structure overlays currently exist for:
-
-- `runtime-console`: assistant-ui/AG-UI run console, Bun/Hono agent gateway,
-  run store, contracts, approvals, artifacts, replay, and telemetry
-- `product-copilot`: in-product copilot panel, AG-UI app-domain events, product
-  context loaders, business action tools, authorization, and approval policies
-- `sidecar-kernel`: Bun/Hono app gateway with Python, Go, or Rust kernels behind
-  MCP tools or narrow HTTP jobs
-- `collaborative-editor`: editor surface with document contracts, CRDT/sync
-  ownership, and user-visible agent action boundaries
-
-Do not turn AI-native overlays into more lettered plans. Do not make A2UI,
-specific model providers, vector DBs, workflow engines, tracing vendors, or
-sidecar languages mandatory defaults.
-
-Scaffold is not an existing-repo adoption path. If the target already has a
-product tree, use `forge adopt`, `forge setup`,
-`forge upgrade`, or `forge repair` and preserve the existing app
-shape. `create-project-dirs`, `hooks-init`, and `docs-init` remain internal
-steps behind public commands, not standalone user-facing scaffold aliases.
-
-## Migration Rules
-
-For legacy repos, migrate old document surfaces before refreshing templates.
-
-Legacy paths include:
-
-- `docs/plan.md`
-- `docs/TODO.md`
-- `docs/PROGRESS.md`
-- `docs/contract.md`
-- `docs/review.md`
-- `docs/handoff.md`
-- `HANDOFF.md`
-
-Use:
-
-- `bun scripts/migrate-workflow-docs.ts --repo <path> --dry-run`
-- `bun scripts/migrate-workflow-docs.ts --repo <path> --apply`
-
-Migration defaults:
-
-- preserve user-authored content
-- archive uncertain legacy content instead of guessing
-- remove repo-local Skill Factory and auto-memory surfaces when present
-- archive legacy `docs/PROGRESS.md` content; do not regenerate it as a default workflow surface
-- keep `tasks/todos.md` limited to deferred medium/long-term goals, including the tradeoff and revisit trigger
-- move hidden contracts and deep findings into topic-scoped `docs/researches/*.md`
-- distill repeated corrections into `tasks/lessons.md`
-- merge missing `external_tooling` defaults into `.ai/harness/policy.json` without overwriting explicit user values
-- keep Waza, gstack, gbrain, Mermaid, and cross-review host skills optional; detect them but never make normal Forge execution depend on them
-- `forge install` bootstraps only Forge-owned runtime and host adapters by default; install third-party host skills only with `--with-external-skills`
-- Forge task routing uses `/direct`, `/plan`, `/debug`, `/review`, `/release`, and `/scale`; optional host skills may refine those workflows when already installed
-- distinguish the bundled CodeGraph read backend used by `rh_context` from an optional global CodeGraph CLI/MCP integration; missing global CLI is not Runtime unready
-
-## Repo-Local Contract
-
-Preserve these semantics:
-
-- `plans/` is the timestamped plan catalog; `.ai/harness/active-plan` selects the active plan, with `.claude/.active-plan` as a legacy fallback during transition
-- `plans/plan-*.md` must carry a workflow inventory before implementation: active plan, owning worktree, contract, review, notes, deferred ledger, checks, run snapshots, scope owner, switching rule, and worktree isolation path
-- `tasks/todos.md` is the deferred-goal ledger; active execution stays in the plan's `## Task Breakdown`
-- `tasks/lessons.md` stores correction-derived rules
-- `docs/researches/*.md` stores deep repo findings and hidden contracts by topic
-- `tasks/contracts/` and `tasks/reviews/` are completion gates
-- `tasks/contracts/*.contract.md` must repeat the workflow inventory and make `allowed_paths` the edit-scope authority
-- `tasks/workstreams/` stores durable capability progress
-- `docs/CHANGELOG.md` stores release history
-- `assets/hooks/` is the installable hook product source; `.ai/hooks/` is a full live runtime only in repos that pin `"hook_source": "repo"`
-- user-level `~/.claude/settings.json` and `~/.codex/hooks.json` are the host adapter surfaces; repo-local `.claude/hooks/`, `.claude/settings.json`, and `.codex/hooks.json` are legacy cleanup targets
-
-## Hook Workflow Protocol
-
-When the task mentions hooks, hook workflow, Codex hook detection, or hook-based
-automation, treat it as a runtime-harness slice, not a generic config edit.
-
-Map the route first:
-
-1. `assets/hooks/` is the installable source.
-2. The active runtime resolves central-first through `forge-hook`; `.ai/hooks/`
-   is a full repo-local implementation only when `"hook_source": "repo"` is pinned.
-3. User-level `~/.claude/settings.json` and `~/.codex/hooks.json` are adapters
-   that dispatch to the packaged `forge-hook` entry or the equivalent `forge hook` CLI route.
-4. Codex also requires the user-level hook config to be trusted in Codex Settings before it
-   executes.
-5. Generated `.claude/hooks/`, repo-local `.claude/settings.json`, and repo-local
-   `.codex/hooks.json` are legacy cleanup targets; preserve only user-authored
-   `custom-*.sh` hooks.
-
-Trace one real event before changing behavior, for example:
-
-`UserPromptSubmit -> adapter -> forge-hook -> prompt-guard.sh -> plan
-or advisory output`
-
-or:
-
-`PostToolUse(Edit|Write) -> adapter -> forge-hook ->
-post-edit-guard.sh -> architecture drift, brain sync, contract verification,
-task handoff`
-
-For Codex hook failures, debug in this order: user-level `~/.codex/hooks.json`,
-Codex Settings trust, `forge-hook` resolution, the active target hook
-script, then `.ai/harness/events.jsonl` or `.claude/.trace.jsonl` evidence.
-
-Hooks are accelerators and guards. They do not replace `plans/`, `tasks/`,
-contracts, reviews, policy, checks, or handoff artifacts. Heavy workflows such as
-autoresearch must not silently run as background hook mutations. The retired
-`autoresearch-advisory.sh` hook is not part of `.ai/hooks`, user-level adapters,
-or installable hook templates. If autoresearch evidence is needed, the agent
-runs it explicitly and keeps local run products under ignored `autoresearch/`
-when they must remain in the workspace.
-
-Verify hook workflow changes with hook-specific evidence:
-
-- default hook asset parity between `assets/hooks/` and `.ai/hooks/`, with
-  no self-host-only hook exclusions
-- `bun test tests/hook-runtime.test.ts tests/workflow-contract.test.ts`
-- `bash scripts/check-task-sync.sh`
-- `bash scripts/check-task-workflow.sh --strict`
-- `bun scripts/inspect-project-state.ts --repo . --format text`
-- `.ai/harness/checks/latest.json`, `.ai/harness/events.jsonl`, or handoff readback
-
-## Output Ownership
-
-This skill may create or update:
-
-- `AGENTS.md`
-- `AGENTS.md`
-- `.ai/hooks/*`
-- `.claude/settings.json`
-- `.codex/hooks.json`
-- `.claude/templates/*`
-- `docs/spec.md`
-- `docs/reference-configs/*.md`
-- `tasks/todos.md`
-- `tasks/lessons.md`
-- `docs/researches/*`
-- `tasks/contracts/*`
-- `tasks/reviews/*`
-- `tasks/workstreams/*`
-- `deploy/README.md`
-- `deploy/sql/*` for ordered deployment SQL files
-- `.ai/harness/*`
-- helper scripts under `scripts/`
-
-## Verification
-
-When changing the engine, migration path, contract manifest, or self-hosted workflow, run:
-
-```bash
-bun run check:task
-bash scripts/check-deploy-sql-order.sh
-bash scripts/check-task-sync.sh
-bash scripts/check-task-workflow.sh --strict
-bash scripts/migrate-project-template.sh --repo . --dry-run
-```
-
-The self-host repository uses content-addressed test governance: ordinary
-verification runs the affected/task gate, and `bun run check:main` reuses that
-focused receipt without expanding to the full suite. Full testing is an
-explicit manual diagnostic, not an ordinary, CI, or release gate.
-
-For migration-focused work, also inspect and dry-run legacy doc migration explicitly:
-
-```bash
-bun scripts/inspect-project-state.ts --repo . --format text
-bun scripts/migrate-workflow-docs.ts --repo . --dry-run
-```
-
-## Iteration Notes
-
-- Keep this file short; detailed policy belongs in `docs/reference-configs/`
-- Keep stack-specific detail in assets and references, not in this skill body
-- If the contract changes, update templates, migration, checks, and tests together

package/adapters/computer/chatgpt-target-router.ts

@@ -1,103 +0,0 @@
-import type {
-  ComputerChatgptConversationIdentity,
-  ComputerChatgptConversationInventory,
-  ComputerChatgptConversationObservationOptions,
-  ComputerChatgptConversationTarget,
-  ComputerChatgptConversationTargetPort,
-  ComputerChatgptTargetIdentity,
-  ComputerChatgptTargetResult,
-} from '../../packages/plugin-runtime/computer';
-
-function identityOf(target: ComputerChatgptConversationTarget): ComputerChatgptTargetIdentity {
-  return target.identity;
-}
-
-export class PreferredChatgptConversationTargetPort implements ComputerChatgptConversationTargetPort {
-  constructor(
-    private readonly primary: ComputerChatgptConversationTargetPort,
-    private readonly compatibility: ComputerChatgptConversationTargetPort,
-  ) {}
-
-  private wrap(primaryTarget: ComputerChatgptConversationTarget, compatibilityTarget?: ComputerChatgptConversationTarget, nativeCompatibility = false): ComputerChatgptConversationTarget {
-    const identity = identityOf(primaryTarget);
-    return {
-      targetId: primaryTarget.targetId,
-      identity,
-      observe: async (options?: ComputerChatgptConversationObservationOptions) => {
-        try { return await primaryTarget.observe(options); }
-        catch (primaryError) {
-          if (compatibilityTarget) return await compatibilityTarget.observe(options);
-          if (identity.namespace === 'chatgpt.conversation') {
-            const fallback = await this.compatibility.ensureExact(identity);
-            if (fallback.state === 'ready') return await fallback.target.observe(options);
-          }
-          throw primaryError;
-        }
-      },
-      prepare: async (prompt, options) => await primaryTarget.prepare(prompt,
-        nativeCompatibility && options?.reasoning ? { ...options, reasoning: undefined } : options),
-      // Only the explicitly selected native fallback lacks a verified reasoning selector.
-      // Preserve a single sender and every other dispatch option; never retry a
-      // possibly submitted effect through a different provider.
-      dispatch: async (prompt, options) => await primaryTarget.dispatch(prompt,
-        nativeCompatibility && options?.reasoning ? { ...options, reasoning: undefined } : options),
-    };
-  }
-
-  async inventory(): Promise<ComputerChatgptConversationInventory> {
-    const [primary, compatibility] = await Promise.all([
-      this.primary.inventory().catch(() => ({ conversations: [], complete: false, unavailableProviders: ['primary'] })),
-      this.compatibility.inventory().catch(() => ({ conversations: [], complete: false, unavailableProviders: ['compatibility'] })),
-    ]);
-    const byId = new Map<string, ComputerChatgptConversationInventory['conversations'][number]>();
-    for (const entry of compatibility.conversations) byId.set(entry.conversationId, entry);
-    for (const entry of primary.conversations) byId.set(entry.conversationId, entry);
-    return {
-      conversations: [...byId.values()],
-      complete: primary.complete || compatibility.complete,
-      unavailableProviders: [...new Set([...primary.unavailableProviders, ...compatibility.unavailableProviders])],
-    };
-  }
-
-  async ensureExact(identity: ComputerChatgptConversationIdentity): Promise<ComputerChatgptTargetResult> {
-    const primary = await this.primary.ensureExact(identity);
-    if (primary.state === 'ready') return { ...primary, target: this.wrap(primary.target) };
-    // An extension that is not connected has made no browser mutation. Reuse
-    // the already available native browser target rather than stranding a due
-    // Supervisor continuation behind an optional transport.
-    if (primary.failure.failoverSafe === true) {
-      const compatibility = await this.compatibility.ensureExact(identity);
-      if (compatibility.state === 'ready') return { ...compatibility, target: this.wrap(compatibility.target, undefined, true) };
-    }
-    return primary;
-  }
-
-  async openBootstrap(projectUrl: string, bootstrapKey: string): Promise<ComputerChatgptTargetResult> {
-    const primary = await this.primary.openBootstrap(projectUrl, bootstrapKey);
-    return primary.state === 'ready' ? { ...primary, target: this.wrap(primary.target) } : primary;
-  }
-
-  async findBySubmittedMarker(marker: string, bootstrapKey?: string, betweenObservations?: () => Promise<void>): Promise<ComputerChatgptTargetResult[]> {
-    const primary = await this.primary.findBySubmittedMarker(marker, bootstrapKey, betweenObservations);
-    if (primary.length > 0) return primary.map((result) => result.state === 'ready' ? { ...result, target: this.wrap(result.target) } : result);
-    return (await this.compatibility.findBySubmittedMarker(marker, bootstrapKey, betweenObservations))
-      .map((result) => result.state === 'ready' ? { ...result, target: this.wrap(result.target, undefined, true) } : result);
-  }
-
-  async promoteBootstrap(targetId: string, identity: ComputerChatgptConversationIdentity): Promise<ComputerChatgptTargetResult> {
-    const primary = await this.primary.promoteBootstrap(targetId, identity);
-    return primary.state === 'ready' ? { ...primary, target: this.wrap(primary.target) } : primary;
-  }
-
-  async cleanup(activeResourceKeys: readonly string[]): Promise<void> {
-    await Promise.allSettled([this.primary.cleanup(activeResourceKeys), this.compatibility.cleanup(activeResourceKeys)]);
-  }
-
-  async release(targetId: string): Promise<void> {
-    await Promise.allSettled([this.primary.release(targetId), this.compatibility.release(targetId)]);
-  }
-
-  async close(): Promise<void> {
-    await Promise.allSettled([this.primary.close(), this.compatibility.close()]);
-  }
-}