version: 1
status: target_canonical
enforcement: Enforced
categories:
  - runtime_debt
  - governance_debt
  - validation_debt
  - operator_ux_debt
  - architecture_debt
  - reconciliation_debt
severity_levels:
  - blocking
  - warning
  - advisory
  - compatibility
  - pending_enforcement
  - observation
  - follow_up
item_types:
  - blocking
  - warning
  - advisory
  - compatibility
  - pending_enforcement
  - observation
  - follow_up
items:
  - id: cfd-0001
    title: close_commit post-success reconciliation/idempotency anomaly
    category: reconciliation_debt
    severity: advisory
    item_type: advisory
    blocking: false
    status: resolved
    source_chunks:
      - chunk-000084-deterministic-approved-action-dispatcher
      - chunk-000093-bounded-autonomy-policy-enforcement
      - chunk-000094-governance-cleanup-authority-principle
    source_sections:
      - Carry Forward
      - Policy Enforcement
    summary: Historical close_commit records can contain failed/stale attempts that were later superseded by successful execution; current close_commit execution is guarded by dispatcher idempotency and reconciliation, but old audit history remains visible.
    evidence: >-
      Timeline entries for close_commit approvals 9618ab3e and 022cb2cf show
      blocked/stale events followed by successful execution. Chunks 000110,
      000111, and 000112 also observed dispatcher stale/failure results while
      trusted daemon helper actions completed the commit successfully. Chunk
      000113 repeated the same failed-then-success timeline; chunk 000114 added
      read-only Runtime Core reconciliation that classifies this shape as
      retry_succeeded while preserving cfd-0001 visibility. Chunk 000115 adds a
      close_commit executing result lock and targeted retry-safe terminal
      failure handling in dispatcher tests; an initially broad retry rule was
      narrowed so background dispatcher loops cannot automatically retry failed
      close_commit records. Chunks 000116, 000119, and 000120 closed through the
      live dispatcher path with executed-success terminal state and no current
      unresolved failed/stale approval. Chunk 000261 added projection-only
      dispatcher actionability to Runtime Health: historical/non-actionable
      dispatcher audit context remains visible, but no-active-chunk health no
      longer presents `current_gate: close_commit` unless a close/commit
      dispatcher action is tied to current chunk or human-review workflow state.
    reason_to_track: Historical retry/failure audit records remain operator-visible and can be mistaken for current actionability.
    owner_surface: Runtime reconciliation / dispatcher audit
    revisit_trigger: A new close_commit approval produces a current unresolved failed-then-success or partially failed state.
    next_action: Keep historical retry/failure records visible as audit context; reopen as pending_enforcement only if a new close_commit approval produces a current unresolved failed-then-success state after the dispatcher idempotency fix.
  - id: cfd-0002
    title: obsolete Codex I/O freeform prompt artifacts
    category: operator_ux_debt
    severity: advisory
    item_type: advisory
    blocking: false
    status: resolved
    source_chunks:
      - chunk-000083-doctor-scorecard-performance-hardening
      - chunk-000084-deterministic-approved-action-dispatcher
      - chunk-000093-bounded-autonomy-policy-enforcement
      - chunk-000097-runtime-event-semantics-telegram-actionability
    source_sections:
      - Carry Forward
      - Policy Enforcement
    summary: Old Codex I/O prompt scraping/freeform flows could surface obsolete operator questions even though dispatcher-owned execution is canonical.
    evidence: Runtime event semantics now classify codex_internal_context as suppressed/non-actionable; codex-io-bridge --mirror-prompts no longer creates operator questions and the bridge fixture test verifies no question file is created.
    reason_to_track: Prompt-scraping artifacts can confuse operator actionability if the suppressed behavior regresses.
    owner_surface: Codex I/O bridge / Runtime event semantics
    revisit_trigger: Obsolete Codex I/O prompt artifacts recur in operator-visible surfaces.
    next_action: If obsolete Codex I/O prompt artifacts recur, reopen this item with the exact rendering path and timeline/operator-question ids.
  - id: cfd-0003
    title: Ready-for-Human-Review approval side-effect automation
    category: governance_debt
    severity: advisory
    item_type: advisory
    blocking: false
    status: resolved
    source_chunks:
      - chunk-000089-governance-validators-doctor-integration
      - chunk-000091-chunk-lifecycle-transition-tooling
      - chunk-000094-governance-cleanup-authority-principle
    source_sections:
      - Carry Forward
      - Policy Enforcement
    summary: Ready-for-Human-Review close/review approval side effect is implemented in canonical transition tooling.
    evidence: Chunk 000118 creates exactly one close_commit approval after Ready validation passes and after the chunk status is updated to Ready for Human Review. Duplicate same-state approvals are suppressed by close-state fingerprint, older same chunk/action approvals are superseded, and lifecycle tests cover automatic creation and duplicate suppression.
    reason_to_track: Approval side-effect automation is authority-sensitive and should be reopened if duplicate or missing approvals recur.
    owner_surface: Runtime Executor lifecycle transition
    revisit_trigger: Ready transitions with recommendation close stop creating fresh approval or create duplicate actionable approvals.
    next_action: Reopen only if Ready transitions with recommendation close stop creating a fresh approval or create duplicate actionable approvals.
  - id: cfd-0004
    title: legacy Telegram TSV projection retired
    category: governance_debt
    severity: follow_up
    item_type: follow_up
    blocking: false
    status: resolved
    source_chunks:
      - chunk-000090-governance-generators-command-docs
      - chunk-000236-telegram-operator-surface-yaml-canonicalization
      - chunk-000254-runtime-action-center-reliability-hardening-assertive-package
      - chunk-000255-fully-retire-legacy-telegram-shell-dispatch
      - chunk-000256-fully-retire-telegram-shell-adapters
    source_sections:
      - Pending Enforcement
      - Policy Enforcement
    summary: The manually maintained Telegram TSV command projection and remaining Telegram shell behavior adapters have been retired. `ai/governance/registries/operator-commands.yaml` is now the canonical Telegram command registry, `ai/tools/telegram/resolve-command.mjs` fails hard on unmodeled commands, and Telegram behavior is owned by Node entrypoints. Shell is retained only for `bridge.sh`, `start-bridge.sh`, `status.sh`, and `stop-bridge.sh` startup/status/process-control wrappers.
    evidence: Governance validator previously reported `telegram_legacy_command_projection_pending`. Chunk 000255 removed `ai/tools/telegram/command-registry.tsv`, expanded YAML to include public, private, event, checkpoint, prompt, chunk, and dynamic Telegram commands, changed governance/runtime operator-surface validation to reject a reintroduced TSV projection, and added `ai/tools/telegram/telegram-bridge.mjs` as the normal bridge entrypoint. Chunk 000256 removed `ai/tools/telegram/lib.sh`, `ask-operator.sh`, checkpoint shell helpers, send-message/send-run-summary shell facades, shell behavior tests, and shell operator-surface validation. Node replacements now own ask-operator, checkpoint wait/consume, send-message, send-run-summary, operator-surface validation, command dispatch, confirmations/questions, outbox/sent/failed receipts, diagnostics, and bridge polling. `node ai/tools/telegram/test/telegram-test.mjs`, `node ai/tools/telegram/validate-operator-surface.mjs`, `ai/governance/validators/validate-generated-help.sh`, `node ai/runtime/dist/cli.js shell-entrypoints`, `node ai/runtime/dist/cli.js governance validate --json`, and `node ai/runtime/dist/cli.js validate --tier fast` pass.
    reason_to_track: Resolved history; reopen only if manually maintained TSV command truth or shell-owned Telegram command dispatch is reintroduced.
    owner_surface: Telegram command projection / governance registry
    revisit_trigger: A manually maintained TSV command registry, TSV fallback, or shell-owned Telegram command truth is reintroduced.
    next_action: Keep Telegram command truth in `operator-commands.yaml`; keep Telegram shell limited to startup/status/process-control wrappers only.
  - id: cfd-0005
    title: emergency-only legacy lifecycle shell paths remain
    category: governance_debt
    severity: follow_up
    item_type: follow_up
    blocking: false
    status: open
    source_chunks:
      - chunk-000091-chunk-lifecycle-transition-tooling
      - chunk-000094-governance-cleanup-authority-principle
    source_sections:
      - Pending Enforcement
      - Policy Enforcement
    summary: Normal lifecycle transition sequencing is Runtime Executor-owned. The remaining direct shell lifecycle file mutation helpers are hard-guarded for explicit severe recovery or preapproved internal close/commit compatibility only.
    evidence: >-
      Runtime SOP and chunk lifecycle docs classify manual lifecycle edits and
      legacy helpers as compatibility-only. Chunk 000120 converted
      transition.sh to a Runtime Executor facade for normal operation. Chunk
      000262 moved `ai/commands/activate-chunk.sh` and
      `ai/commands/complete-chunk.sh` into the
      `emergency_lifecycle_recovery` shell-entrypoint category.
      `activate-chunk.sh` now fails loudly unless
      `RUNTIME_ALLOW_LEGACY_LIFECYCLE_SHELL=true` is set.
      `complete-chunk.sh` no longer creates workflow approvals itself; it only
      runs with a valid `WORKFLOW_APPROVAL_RECORD`, or explicit emergency
      override plus a valid approval record.
      `node ai/runtime/dist/cli.js shell-entrypoints --json` reports 136/136
      shell scripts classified and exactly two `emergency_lifecycle_recovery`
      paths.
    reason_to_track: Emergency lifecycle recovery paths are intentionally retained but must not become normal authority-state mutation paths.
    owner_surface: Runtime lifecycle helpers / chunk transition tooling
    revisit_trigger: >-
      `ai/commands/activate-chunk.sh` or `ai/commands/complete-chunk.sh` is
      used outside explicit severe recovery/preapproved dispatcher
      compatibility, or a typed Draft/Backlog activation owner is added.
    next_action: >-
      Keep `activate-chunk.sh` and `complete-chunk.sh` emergency-only and
      hard-guarded. Replace the remaining activation recovery path with a typed
      Runtime lifecycle owner only if Draft/Backlog activation becomes normal
      workflow again.
  - id: cfd-0006
    title: Runtime Action Panel technical naming compatibility
    category: architecture_debt
    severity: compatibility
    item_type: compatibility
    blocking: false
    status: open
    source_chunks:
      - chunk-000160-admin-runtime-action-panel-refinement
      - chunk-000163-ui-route-label-and-naming-consistency-crosscheck
      - chunk-000167-carry-forward-role-standards-summary-integration
    source_work_packages:
      - work-package-000003-admin-runtime-health-dashboard
    source_sections:
      - Carry Forward
      - Details
      - Handoff
    summary: User-facing page naming is Runtime Action Panel, while compatible route/API/component names still use Admin Runtime Health, adminRuntimeHealth, and /admin/health.
    evidence: Chunk 000160 preserved /admin/health and AdminRuntimeHealth technical contracts while changing the user-facing page to Runtime Action Panel. Chunk 000163 explicitly documented retained Health/AdminRuntimeHealth naming as compatibility.
    reason_to_track: Intentional naming mismatch is useful compatibility debt and should not be forgotten during future route/API or export naming work.
    owner_surface: Admin Runtime Action Panel / GraphQL / frontend route compatibility
    revisit_trigger: A future route/API/component rename, navigation label change, export naming change, or public documentation update touches Runtime Action Panel/Admin Runtime Health naming.
    next_action: Preserve /admin/health compatibility until a dedicated migration chunk proves a safe route/API/file rename; update docs/exports when touched.
  - id: cfd-0007
    title: backend e2e requires configured test database
    category: validation_debt
    severity: warning
    item_type: warning
    blocking: false
    status: open
    source_chunks:
      - chunk-000152-admin-runtime-handoff-export-controls
      - chunk-000159-app-shell-navigation-tests-docs-accessibility
      - chunk-000200-backend-e2e-safe-test-database-harness-cfd-0007
      - chunk-000206-environment-parity-test-database-cfd-0007
    source_sections:
      - Carry Forward
      - Validation
      - Handoff
    summary: Backend e2e remains environment-dependent for actual database coverage, but routine validation now skips safely with a clear warning unless TEST_DATABASE_URL or a test-named database is configured. Local/dev env parity is checked by yarn env:check, and the documented convention is TEST_DATABASE_URL=postgres://postgres:postgres@db:5432/app_test inside the devcontainer network.
    evidence: Chunks 000152 and 000159 record backend e2e as blocked unless TEST_DATABASE_URL or a test-named database is configured. Chunk 000200 changed the e2e harness to skip safely with an explicit warning when no safe test database is configured, preserving the destructive reset guard while allowing routine canonical validation to proceed. Chunk 000206 added env parity checking, clarified db:5432 versus host localhost:35432, and documented app_test as the canonical local test database name.
    reason_to_track: The condition recurs during validation and can be mistaken for product regression rather than environment setup; skipped e2e means database-backed API coverage was not exercised.
    owner_surface: Backend e2e / Prisma test database configuration
    revisit_trigger: Backend e2e is required for a chunk, CI test database setup changes, or Prisma/database work is planned.
    next_action: Provision the app_test database locally or in CI when database-backed e2e coverage is required; keep yarn env:check and the safe e2e skip warning visible when TEST_DATABASE_URL is absent.
  - id: cfd-0008
    title: frontend bundle and Admin Health SCSS warning budgets remain
    category: validation_debt
    severity: warning
    item_type: warning
    blocking: false
    status: open
    source_chunks:
      - chunk-000153-admin-health-role-activity-live-status-polish
      - chunk-000154-navigation-registry-app-shell-config
      - chunk-000158-mobile-dropdown-overflow-replacement
      - chunk-000159-app-shell-navigation-tests-docs-accessibility
      - chunk-000160-admin-runtime-action-panel-refinement
    source_sections:
      - Carry Forward
      - Bad
      - Ugly
      - Validation
    summary: Frontend builds pass, but the initial bundle and Admin Health/Runtime Action Panel styling remain over warning-level budgets or close to hard budget ceilings.
    evidence: Chunks 000153, 000154, 000158, 000159, and 000160 repeatedly report warning-level frontend bundle/Admin Health SCSS budget overages. Chunk 000160 reduced the hard SCSS budget risk but left warning-level budgets.
    reason_to_track: Small UI additions can turn warning-level budget debt into noisy validation output or a hard budget error.
    owner_surface: Angular frontend build budgets / Runtime Action Panel styles
    revisit_trigger: Runtime Action Panel/App Shell UI changes add significant styles or bundles, or frontend build warnings become operationally noisy.
    next_action: Plan a focused frontend budget cleanup if warnings worsen, become hard errors, or block UI work.
  - id: cfd-0009
    title: Playwright browser tooling pinning and invocation guidance
    category: validation_debt
    severity: observation
    item_type: observation
    blocking: false
    status: open
    source_chunks:
      - chunk-000070-dev-console-login-routing-tmux-integration
      - chunk-000153-admin-health-role-activity-live-status-polish
      - chunk-000159-app-shell-navigation-tests-docs-accessibility
    source_sections:
      - Lessons Learned
      - Carry Forward
      - Validation
    summary: Browser review works best with the pinned Playwright/Chromium setup and managed server URL; the workspace may rely on `npx playwright@1.59.1` even when the package is not installed locally.
    evidence: Chunk 000070 documented the known-good screenshot route, chunk 000153 recorded pinned Playwright usage, and chunk 000159 noted cached Chromium binaries with no workspace Playwright package.
    reason_to_track: UI QA can regress into false browser-unavailable claims if the pinned command and managed server assumptions are forgotten.
    owner_surface: UI review / Playwright browser smoke / Docker development image
    revisit_trigger: UI/browser review policy changes, Docker image Playwright version changes, or browser smoke becomes a hard validation gate.
    next_action: Keep using the pinned Playwright command documented in UI/runtime standards until a dedicated dependency/tooling chunk changes it.
  - id: cfd-0010
    title: Runtime boundedness degrades after close_commit bursts
    category: runtime_debt
    severity: follow_up
    item_type: follow_up
    blocking: false
    status: superseded
    source_chunks:
      - chunk-000141-runtime-boundedness-maintenance-reconciliation
      - chunk-000142-runtime-health-work-package-current-gate-reconciliation
      - chunk-000143-runtime-health-state-vocabulary-hardening
      - chunk-000167-carry-forward-role-standards-summary-integration
    source_sections:
      - Carry Forward
      - Ugly
      - Validation
      - Details
    summary: Close/commit and dispatcher bursts can push action timeline and audit hot windows over boundedness thresholds, causing Runtime Health validation to show degraded until canonical archive/maintenance runs.
    evidence: Chunk 000141 resolved timeline/audit boundedness by canonical maintenance. Chunks 000142, 000143, and 000167 observed that close/commit activity can push hot-window counts back over limits.
    reason_to_track: The degradation is real and should remain visible, but it is operational maintenance debt rather than proof that overall Runtime execution failed.
    owner_surface: Runtime action timeline / audit boundedness maintenance
    revisit_trigger: Runtime Health validation reports degraded boundedness after normal close/commit bursts, or maintenance becomes frequent enough to interrupt chunk flow.
    next_action: Plan bounded maintenance automation or a clearer canonical archive cadence; do not hide degraded boundedness or add UI mutation controls as a workaround.
  - id: cfd-0011
    title: Runtime Health role activity lacks scheduled and live work-session visibility
    category: operator_ux_debt
    severity: follow_up
    item_type: follow_up
    blocking: false
    status: open
    source_chunks:
      - chunk-000145-runtime-health-role-activity-projection
      - chunk-000153-admin-health-role-activity-live-status-polish
      - chunk-000169-websocket-handshake-invalid-token-hardening
      - chunk-000172-runtime-live-update-event-surface-completeness
      - chunk-000176-runtime-work-session-activity-projection
      - chunk-000187-runtime-action-panel-exact-work-detail-display
      - chunk-000190-runtime-action-panel-liveness-confidence-contract
      - chunk-000235-automatic-work-step-emission-cfd-0011
      - chunk-000254-runtime-action-center-reliability-hardening-assertive-package
      - chunk-000260-runtime-work-registration-coverage-expansion
      - chunk-000285-overnight-runtime-execution-policy-package-summary
      - chunk-000293-role-work-visibility-e2e-proof-harness
    source_sections:
      - Carry Forward
      - Handoff
    summary: Runtime Health role activity can show active and idle lifecycle-derived role states, chunk 000176 adds a separate runtime_work_session projection for live in-between Orchestrator/Codex work, and chunk 000190 adds a Runtime-owned liveness confidence contract for work sessions and work steps. Chunk 000217 added clearer direct-chunk role semantics for not-applicable upstream roles, scheduled QA, planned Chunk Planner, and passed Runtime Executor validation. Chunk 000235 made Runtime-owned bounded test and workspace spec wrappers emit automatic Runtime work-session/work-step start and terminal completion/failure evidence. Chunk 000254 added automatic Runtime Executor work-session/work-step emission for the Runtime validation API and typed Runtime supervisor action execution. Chunk 000260 added required registration metadata to Runtime test, backend/frontend spec, browser smoke, and supervisor wrappers, and added automatic registration for summary validation, governance validation, audit archive execution, and action timeline archive execution. Remaining debt is per-role concurrent detailed work steps, future typed QA review executor coverage, and dispatcher-path registration only if it can be added inside canonical dispatcher execution without changing authority.
    evidence: During chunk 000169, the Health panel correctly did not mark QA active while focused developer validation was running, but the operator noted that QA being scheduled or expected would be useful context. During chunk 000172, the operator noted that no role was blinking while Orchestrator was still performing follow-up validation/artifact cleanup after the active chunk had reached Ready for Human Review. Runtime Health correctly projected the lifecycle boundary as human review, but it lacked a separate live work-session/progress activity signal. Chunk 000176 adds Runtime-owned runtime_work_session state for active/stale/idle in-between work without reactivating lifecycle gates. During chunk 000187, operator review found that old active work steps could keep Developer appearing active in the UI after work had stopped. The implementation tightened frontend freshness guards and Runtime recent-step stale projection, and changed work-step start to complete the previous current step before starting the new step, with journaled work_step.completed and work_step.started events. Chunk 000190 adds liveness_confidence, liveness_reason, confidence_updated_at, and heartbeat_age_seconds to runtime_work_session and runtime_work_step, and gates frontend active/pulse rendering on Runtime-provided fresh confidence. During chunk 000217, the authenticated browser proof exposed that ad hoc verification commands were not automatically represented as active work until an explicit Runtime work-step was started; the browser report also validated the direct-chunk projection where upstream requirements roles are not_applicable, QA is scheduled_after_implementation, Runtime Executor is validation_passed, and Developer is active only with fresh Runtime work-step evidence. Chunk 000235 proved `testing runtime-broad-tests --phase stateSurfaces` leaves a completed Runtime Executor `runtime_tests` work step and completed wrapper session, while the child `runtime-test.mjs` work-session fixture is isolated under the durable test report path. It also proved `testing frontend-specs --include src/app/features/admin-health/services/runtime-action-center.facade.spec.ts` leaves a completed Runtime Executor `frontend_tests` work step, and `testing no-output-timeout-smoke` leaves failed Runtime Executor session/step evidence with `testing_channel_timeout` report metadata. Chunk 000254 added Runtime-owned work-session/work-step emission around `validation.run`, `validation.profileRun`, and `runRuntimeSupervisorOnce`; focused daemon and supervisor tests assert journaled started/completed/failed work events for validation and supervisor execution. Chunk 000260 records the coverage matrix at `ai/reports/report-000260-work-registration-coverage-matrix.yaml` and tests automatic registration for summary validation, governance validation, and timeline archive maintenance. Chunk 000285 confirmed the overnight package left Runtime Health healthy after bounded maintenance and kept cfd-0011 open only for the already-scoped future typed QA executor, dispatcher-path registration, and optional per-role concurrent detail. Chunk 000293 added a browser proof mode that lights explicit role cards for the full role matrix only when fresh Runtime work steps are registered, proves Developer parent work remains represented while Runtime Executor foreground child work runs, and proves the parent is restored after child completion.
    reason_to_track: Operators need to distinguish role inactivity from planned next-role responsibility and from live in-between Orchestrator/Codex work. Otherwise correct lifecycle states can look like missing activity, while overloading gates or trusting stale client timers would create false active states.
    owner_surface: Runtime Health role activity projection / Runtime Action Panel
    revisit_trigger: Future Runtime Action Panel role activity, QA scheduling, chunk lifecycle, or workflow-state projection work touches role activity semantics.
    next_action: >
      Keep automatic work-step emission on Runtime-owned validation, testing,
      browser-smoke, typed supervisor, summary validation, governance
      validation, and bounded maintenance paths. Add auto-registration to a
      future typed QA review executor once that path exists. Consider
      dispatcher-path registration only inside canonical dispatcher execution
      without changing approval or close/commit authority. Add a per-role
      active-step projection only if concurrent role-specific detail is still
      required. Keep the chunk 000190 liveness-confidence rule enforced:
      active/blinking UI requires Runtime-provided fresh confidence, and
      frontend elapsed timers are display-only.
  - id: cfd-0012
    title: Runtime live-update event surface completeness
    category: architecture_debt
    severity: follow_up
    item_type: follow_up
    blocking: false
    status: resolved
    source_chunks:
      - chunk-000170-admin-ui-consistency-operator-ergonomics-crosscheck
      - chunk-000171-runtime-live-status-message-semantics
      - chunk-000172-runtime-live-update-event-surface-completeness
      - chunk-000177-runtime-state-engine-journal-contract
      - chunk-000178-runtime-work-session-journal-integration
      - chunk-000179-runtime-health-socket-journal-consumer
      - chunk-000180-high-value-state-surface-journal-producers
      - chunk-000181-live-health-panel-journal-verification-cfd-0012-reconciliation
      - chunk-000182-runtime-state-journal-producer-coverage-live-ui-proof
      - chunk-000184-runtime-work-session-step-granularity-cfd-0012-split
    source_sections:
      - Carry Forward
      - Handoff
    summary: Superseded broad Runtime live-update event surface bundle. Runtime Health live updates now have Socket.IO invalidation/refetch, fallback file watchers, and a Runtime State Change Journal path for covered surfaces. Chunk 000184 split the remaining broad scope into precise actionable CFD items.
    evidence: Chunk 000170 found that socket invalidation previously depended on backend-observed health snapshots and did not reliably emit when local Runtime/chunk files changed. The chunk added a narrow backend file invalidation bridge, but this is not the same as a complete canonical Runtime event-source audit. Chunk 000171 narrowed the live status-message surface by making app-shell Runtime Health refreshes network-backed, queueing one follow-up refresh when socket invalidation arrives mid-flight, and making Runtime Health emit a continuous role roster so QA and other potential workflow roles do not disappear when idle. Chunk 000172 broadened the backend file invalidation bridge to path-specific Runtime surfaces for operator questions/answers/approved actions, dispatcher results, runtime supervisor state, carry-forward registry changes, audit index changes, and timeline boundedness; it also broadened snapshot-diff signatures for runtime availability, owners, authority, operations, leases, human actions, role activity activity/scope, and recommended next action. Chunks 000177-000180 add the Runtime State Engine / State Change Journal contract, work-session producer events, journal-preferred socket invalidation, and runtime concurrency producer events. Chunk 000181 verified Runtime Health snapshot truth reports active chunk 000181, role details for 000181, and active work-session event records for 000181; backend health is reachable on port 3720 and frontend is reachable on 4220. Chunk 000182 added bounded socket invalidation metadata, frontend query-family invalidation routing, and a live-update coverage matrix in ai/reports/report-000011-runtime-action-panel-live-update-coverage.md. Chunk 000184 split the remaining uncertainty into precise items for authenticated browser/socket proof, lifecycle/work-package producers, human action/approval/dispatcher producers, consultant checkpoint producers, validation/runtime availability producers, and timeline/audit journal boundary decision. Chunk 000262 reconciled this broad item as superseded; remaining live-update/journal gaps are tracked by precise CFDs instead of this umbrella.
    reason_to_track: Operators expect Role Activity, current gate, validation, boundedness, dispatcher, and handoff state to update live without manual refresh; partial invalidation coverage can make the dashboard appear stale even when GraphQL snapshot truth is correct after refresh.
    owner_surface: Runtime Health Socket.IO invalidation / Runtime event sources / backend file invalidation bridge
    revisit_trigger: Reopen only if a future broad live-update regression cannot be assigned to the precise superseding CFD items.
    next_action: Keep this umbrella closed; use the superseding precise CFD items instead of adding new scope here.
    superseded_by: cfd-0014 through cfd-0019
  - id: cfd-0013
    title: Admin UI style primitives and tab bar polish need centralization audit
    category: architecture_debt
    severity: follow_up
    item_type: follow_up
    blocking: false
    status: open
    source_chunks:
      - chunk-000170-admin-ui-consistency-operator-ergonomics-crosscheck
      - chunk-000173-canonical-dry-ui-md-definition-audit
    source_sections:
      - Carry Forward
      - Handoff
    summary: Admin surfaces now share some card/header styling through global utility classes, but page-local card/header/form/status styles still exist across Runtime Action Panel, Dev Console, Nav, Settings, and overview surfaces; the default iOS tab bar has translucent/blur CSS but still needs browser-verified visual polish if it does not read as truly frosted in the running app.
    evidence: Chunk 000170 introduced shared `.card-kicker` header styling, tightened several local pages, and added bottom-fixed/translucent/backdrop-filter styling for the iOS tab bar. Operator review identified that the card headers were not fully normalized across the whole UI and the tab bar still did not visually appear frosted enough in the actual app. Chunk 000173 confirmed that shared primitives exist for `ui-card`, `ui-badge`, `ui-button`, `ui-form-field`, app-shell connection notification, and mobile tab bar, but page-local Runtime Action Panel, Dev Console, Nav/Admin, Settings, form/status, and card/header classes still remain. Connection recovery, toasts, card headers, theming, tab bar variants, and UI status primitives should come from app-shell or central UI/library sources rather than page-specific fixes.
    reason_to_track: Repeated page-local UI fixes create drift between Admin pages and make future navigation, theming, and connection-status behavior harder to reason about.
    owner_surface: Frontend UI primitives / App Shell / Admin pages / theming
    revisit_trigger: Future Admin UI polish, theme-system, Runtime Action Panel, App Shell, Settings, mobile tab bar, or card/form/status indicator work touches shared visual primitives.
    next_action: Audit Admin UI cards, headers, form controls, status dots, connection banners, tab bar style variants, and theme primitives; promote common patterns into shared UI components/classes/services while preserving intentional per-page overrides. Browser-verify the iOS tab bar frost/translucency and adjust the shared tab bar style until it is visually distinct from the custom/floating style. Keep app-shell connection notification and mobile tab-bar behavior centralized rather than adding page-specific recovery or style fixes.
  - id: cfd-0014
    title: Authenticated browser and Socket.IO E2E live-update proof
    category: validation_debt
    severity: follow_up
    item_type: follow_up
    blocking: false
    status: open
    source_chunks:
      - chunk-000182-runtime-state-journal-producer-coverage-live-ui-proof
      - chunk-000184-runtime-work-session-step-granularity-cfd-0012-split
      - chunk-000210-runtime-service-journal-and-timeline-boundary-cfds
      - chunk-000201-runtime-availability-validation-journal-producer-coverage-cfd-0018
      - chunk-000194-runtime-service-freshness-controller-and-operator-notification
      - chunk-000197-runtime-action-panel-service-health-reliability-proof
      - chunk-000217-runtime-action-panel-playwright-pwa-browser-proof
      - chunk-000218-runtime-state-journal-stream-invalidation-consumer
      - chunk-000241-socket-device-cleanup-stale-proof
      - chunk-000247-operator-message-stream-passive-browser-proof
    source_sections:
      - Carry Forward
      - Validation
    summary: Authenticated desktop/mobile-browser Socket.IO live-update proof now exists for the Runtime Action Panel, and generic browser socket-device cleanup is proven. Remaining proof debt is installed iPhone/PWA-specific delivery and backend-owned planned restart/disconnect reason toasts.
    evidence: >-
      Chunk 000182 proved backend metadata, frontend invalidation routing, and
      canonical GraphQL refetch behavior with tests, but recorded that
      authenticated browser/socket proof was not practical in that turn. Chunk
      000184 split this proof gap out of the former broad cfd-0012 bundle.
      During the first chunk 000217 attempt, the browser proof reached an
      authenticated Runtime Action Panel, showed backend-owned admin socket
      diagnostics, rendered the initial Runtime work step, and received a
      runtime_work_session/runtime_work_step socket invalidation, but did not
      observe the follow-up adminRuntimeHealth GraphQL refetch. Chunk 000218
      replaced watcher-primary invalidation with a Runtime State Journal
      consumer path. The resumed chunk 000217 proof produced
      `ai/reports/report-000024-20260517-runtime-action-panel-browser-smoke.md`
      with PASS evidence: authenticated admin browser reached the Runtime
      Action Panel, backend-owned socket diagnostics showed admin device
      membership, a Runtime state change reached the browser through socket
      invalidation and canonical GraphQL refetch, the visible work-step marker
      changed from the initial marker to the invalidation marker,
      connection-lost/minimized/restored toasts rendered, and signed-out access
      was blocked. The proof also restored normal role-card display semantics by
      keeping proof diagnostics test-scoped and rendering not_applicable roles,
      scheduled QA, and validation-passed Runtime Executor from Runtime/GraphQL
      truth. Chunk 000241 updated backend socket diagnostics so current
      connected-device counts are based on unique user/browser-device identity,
      superseded socket records are marked as bounded `stale` history, and
      authenticated mobile Chromium browser proof opens a second admin context
      with the same device id to verify the duplicate does not inflate current
      connected-device count while stale history remains visible. During chunk
      000247, the full browser smoke intermittently failed before the new
      message-stream proof because the duplicate-context step observed
      connected-device count 2 instead of the previously expected stable count
      1. The chunk then added a scoped message-stream browser proof mode so
      unrelated duplicate-device flakiness does not block other live-update
      surfaces.
    reason_to_track: Socket.IO can be correctly wired in unit tests while browser authentication, room membership, reconnect timing, or app-shell service behavior still prevents live operator updates.
    owner_surface: Runtime Health Socket.IO / Admin Runtime Action Panel / authenticated browser harness
    revisit_trigger: Future Socket.IO, auth/session, browser smoke, Runtime Action Panel, or live-update verification work touches authenticated delivery.
    next_action: Keep the browser proof command available as the baseline live-update regression check. Revisit the duplicate-context current-device-count assertion and backend/browser registry behavior before relying on that proof as non-flaky. Plan separate installed iPhone/PWA proof and restart-recovery proof. Planned Runtime/backend restarts should emit a backend-owned reason/actor before disconnect so the app-shell toast can distinguish intentional maintenance from unexpected connection loss.
  - id: cfd-0015
    title: Lifecycle and work-package journal producer coverage
    category: architecture_debt
    severity: follow_up
    item_type: follow_up
    blocking: false
    status: open
    source_chunks:
      - chunk-000182-runtime-state-journal-producer-coverage-live-ui-proof
      - chunk-000184-runtime-work-session-step-granularity-cfd-0012-split
    source_sections:
      - Carry Forward
    summary: Chunk lifecycle transition journal producer coverage is now implemented at the Runtime Executor owner. Active/completed work-package/archive state remains the precise remaining gap.
    evidence: Chunk 000182 identified current gate/chunk lifecycle and active/completed work-package/archive changes as remaining fallback-only or not fully proven journal producer surfaces. Chunk 000184 split this from the broad cfd-0012 bundle. Chunk 000262 added non-authority `chunk_lifecycle` Runtime State Journal events after successful Runtime Executor lifecycle transitions and registered `chunk_lifecycle` as covered in `runtime state-surfaces`. Work-package lifecycle/archive mutation ownership remains separate and should not be covered by compatibility wrappers.
    reason_to_track: Operators expect current gate and work-package state to update live, but lifecycle authority must not be weakened by casual producer hooks.
    owner_surface: Chunk lifecycle / work-package lifecycle / Runtime State Change Journal
    revisit_trigger: Future work-package lifecycle, archive, Runtime Health, or journal producer work touches active/completed work-package or work-package archive state.
    next_action: Add journal producers only at canonical work-package lifecycle/archive mutation points, or document compatibility fallback if ownership remains authority-sensitive. Do not add producers at shell compatibility wrappers.
  - id: cfd-0016
    title: Dispatcher result journal producer coverage remains
    category: architecture_debt
    severity: follow_up
    item_type: follow_up
    blocking: false
    status: open
    source_chunks:
      - chunk-000182-runtime-state-journal-producer-coverage-live-ui-proof
      - chunk-000184-runtime-work-session-step-granularity-cfd-0012-split
    source_sections:
      - Carry Forward
    summary: Runtime Executor now emits non-authority journal records for operator question creation, approved-action registration, and approved-action resolution/supersession. The remaining precise gap is dispatcher result execution coverage from the guarded dispatcher owner.
    evidence: Chunk 000182 identified operator questions/approvals and dispatcher authority-adjacent surfaces as remaining live-update producer gaps. Chunk 000184 split this from the broad cfd-0012 bundle. Chunk 000262 added non-authority Runtime State Journal producers at the Runtime Executor owner for `operator_question.created`, `approved_action.registered`, and `approved_action.resolved`, and changed the `operator_questions_and_approvals` surface to covered. `approved_action_dispatcher_results` remains planned because guarded dispatcher execution is still shell/action-timeline-owned and should move to a typed dispatcher owner before being marked journal-covered.
    reason_to_track: Dispatcher results are high-value live surfaces, but producer hooks must not alter approval, close/commit, or dispatcher authority.
    owner_surface: Runtime Executor / operator questions / approved-action dispatcher / Runtime State Change Journal
    revisit_trigger: Future dispatcher, close/commit, approved-action execution, Telegram/operator notification, Runtime Action Panel human-action, or journal producer work touches dispatcher result execution.
    next_action: Move guarded dispatcher result execution to a typed Runtime/Node owner or add a producer at that canonical owner, then mark `approved_action_dispatcher_results` covered. Do not add producer hooks in compatibility wrappers that would obscure dispatcher authority.
  - id: cfd-0017
    title: Consultant checkpoint journal producer coverage
    category: architecture_debt
    severity: follow_up
    item_type: follow_up
    blocking: false
    status: resolved
    source_chunks:
      - chunk-000182-runtime-state-journal-producer-coverage-live-ui-proof
      - chunk-000184-runtime-work-session-step-granularity-cfd-0012-split
    source_sections:
      - Carry Forward
    summary: Consultant checkpoint mutation coverage is implemented at the Runtime consultant checkpoint module owner.
    evidence: Chunk 000182 identified consultant checkpoints as a remaining producer coverage gap. Chunk 000184 split this from the broad cfd-0012 bundle. Chunk 000262 added advisory-only Runtime State Journal producers after lease-protected consultant response import and plan-revision recommendation recording, and registered `consultant_checkpoints` as covered in `runtime state-surfaces`.
    reason_to_track: Consultant checkpoint state can affect operator review and next-action visibility, but its source paths and mutation owners must be explicit before journal hooks are added.
    owner_surface: Consultant checkpoint artifacts / Runtime Health / Runtime State Change Journal
    revisit_trigger: Reopen only if consultant checkpoint mutation paths are added outside the Runtime consultant checkpoint module or stop emitting advisory-only journal events.
    next_action: Keep consultant checkpoint producers at the Runtime module owner; do not add shell-owned checkpoint producers.
  - id: cfd-0018
    title: Validation and runtime availability journal producer coverage
    category: architecture_debt
    severity: follow_up
    item_type: follow_up
    blocking: false
    status: resolved
    source_chunks:
      - chunk-000182-runtime-state-journal-producer-coverage-live-ui-proof
      - chunk-000184-runtime-work-session-step-granularity-cfd-0012-split
      - chunk-000210-runtime-service-journal-and-timeline-boundary-cfds
    source_sections:
      - Carry Forward
    summary: Validation/cache completion, Runtime API daemon status transitions, service-readiness functional-probe degraded/recovered classifications, restart_required/restart_cleared classifications, and supervised recovery started/succeeded/failed evidence are journal-covered.
    evidence: Chunk 000182 identified validation/cache completion and runtime availability/freshness as remaining producer coverage gaps. Chunk 000184 split these from the broad cfd-0012 bundle. During chunk 000193, the backend was reachable while Runtime Health reported unavailable because the Runtime daemon required restart after runtime source/build/generation hashes changed; manual daemon restart restored runtime_available=true. Chunk 000194 added bounded Runtime API functional probe/status projection and supervised Runtime API restart action support. Chunk 000197 proved Action Panel service-health projection includes Runtime API functional probe/freshness/recovery status and backend-owned service rows for Backend API and Socket.IO diagnostics. Chunk 000201 added State Change Journal producers for Runtime API daemon status transitions, changed-only validation completion, full validation shell start/completed/failed events, validation cache verification, and validation cache invalidation. Chunk 000210 added service-readiness journal events for functional_probe.degraded, functional_probe.recovered, runtime.restart_required, runtime.restart_cleared, service.recovery_started, service.recovery_succeeded, and service.recovery_failed.
    reason_to_track: Runtime Action Panel liveness depends on validation and runtime service state, but availability/freshness can be derived from daemon files and must not be guessed by the frontend.
    owner_surface: Runtime validation/cache / runtime daemon freshness / Runtime Health / Runtime State Change Journal
    revisit_trigger: Future validation cache, runtime daemon, service readiness, Runtime Health, or journal producer work removes or bypasses these producer hooks.
    next_action: Keep service-readiness and validation producer hooks current when Runtime availability or validation status semantics change.
  - id: cfd-0019
    title: Timeline and audit journal boundary decision
    category: architecture_debt
    severity: follow_up
    item_type: follow_up
    blocking: false
    status: resolved
    source_chunks:
      - chunk-000182-runtime-state-journal-producer-coverage-live-ui-proof
      - chunk-000184-runtime-work-session-step-granularity-cfd-0012-split
      - chunk-000210-runtime-service-journal-and-timeline-boundary-cfds
    source_sections:
      - Carry Forward
    summary: Timeline and audit remain separate canonical audit/boundedness surfaces; State Change Journal records only bounded-maintenance boundary events for archive actions.
    evidence: Chunk 000182 identified timeline/audit journal-vs-watcher semantics as a remaining decision. Chunk 000184 split this from the broad cfd-0012 bundle. Chunk 000210 decided not to merge or alias the action timeline/audit indexes into the State Change Journal. Instead, `ai/commands/runtime-bounded-maintenance.mjs` emits bounded State Change Journal events for `timeline.boundedness_archived` and `audit.boundedness_archived` after canonical archive execution, preserving audit boundedness semantics while giving Runtime Health invalidation/index consumers a journal-visible boundary event.
    reason_to_track: Action timeline already resembles a journal, but repurposing it casually could compromise audit boundedness semantics; leaving it watcher-only keeps live behavior more fragile.
    owner_surface: Runtime action timeline / audit index / Runtime State Change Journal
    revisit_trigger: Future timeline boundedness, audit index, state journal, maintenance, or Runtime Health liveness work proposes merging audit/timeline with the State Change Journal or bypassing bounded maintenance events.
    next_action: "Preserve the separation: timeline/audit remain canonical audit surfaces; journal records bounded-maintenance boundary events only."
  - id: cfd-0020
    title: Assistant final chat summary enforcement remains policy-bound
    category: governance_debt
    severity: pending_enforcement
    item_type: pending_enforcement
    blocking: false
    status: open
    source_chunks:
      - chunk-000173-canonical-dry-ui-md-definition-audit
    source_sections:
      - Carry Forward
      - Policy Enforcement
      - Ugly
    summary: Chunk artifacts, Runtime summaries, Telegram details, and validators define canonical run-summary sections, but assistant final chat responses cannot be mechanically enforced by repository tooling in every session.
    evidence: Chunk 000173 made `ai/standards/runtime-sop.md` and `ai/standards/workflow-output-quality.md` explicit that chunk/package completion, stop-condition, close/commit, and operator-review final chat responses must include or mirror the canonical Details, Good, Bad, Ugly, Validation, and Next structure. Repository validators can check chunk artifacts and Runtime/Telegram summary rendering, but the final chat message itself remains a policy-bound operator/QA review surface rather than a guaranteed machine-enforced output.
    reason_to_track: Operators can miss important Good/Bad/Ugly/Validation/Next context if final chat output drifts away from canonical Runtime summaries, even when the markdown artifact is correct.
    owner_surface: Orchestrator final responses / Runtime summary rendering / workflow output quality
    revisit_trigger: Future summary renderer, Codex/assistant integration, workflow-output validator, Telegram details, or final-response automation work can mechanically validate or generate assistant final chat output.
    next_action: Prefer rendering or mirroring the canonical Runtime summary for final chat responses; add platform/tooling enforcement if a future integration can validate or generate assistant final responses directly.
  - id: cfd-0021
    title: Local complete/commit path can bypass Telegram completion summaries
    category: governance_debt
    severity: pending_enforcement
    item_type: pending_enforcement
    blocking: false
    status: resolved
    source_chunks:
      - chunk-000191-runtime-workflow-artifact-index-contextual-export-surface
      - chunk-000193-socket-io-compression-and-health-snapshot-size-check
      - chunk-000195-telegram-delivery-health-outbox-lag-operator-notification-evidence
      - chunk-000198-close-commit-notification-path-enforcement
    source_sections:
      - Carry Forward
      - Bad
      - Ugly
    summary: Every canonical close/commit path now either uses Runtime Executor run-summary/operator notification ownership or records durable close-commit notification-contract evidence explaining why a separate completion note is not applicable.
    evidence: During chunk 000191, `node ai/runtime/dist/cli.js telegram status --json` reported the Telegram bridge RUNNING, but `telegram details --json` still pointed to an older chunk run summary. A catch-up run summary for chunks 000189, 000188, and 000173 was sent successfully with `node ai/tools/telegram/send-run-summary.mjs`, proving the bridge was available and the gap was the close/commit invocation path rather than transport downtime. Chunk 000193 fixed autonomous/deemed approval metadata preservation and completion-note framing regressions. Chunk 000195 added sent/failed delivery receipts and delivery health projection, narrowing transport observability. Chunk 000198 added `ai/tools/operator-notifications/record-close-commit-contract.sh`, dispatcher evidence for manual and autonomous close_commit success, compatibility evidence in `close-commit-approved.sh` and `complete-chunk.sh`, regression tests, and `ai/reports/report-000012-20260517-close-commit-notification-path-matrix.md`.
    reason_to_track: Operators expect chunk completion notes in Telegram; direct local complete/commit workflows can silently skip the Runtime Executor run-summary path unless this is enforced.
    owner_surface: Runtime Executor run-summary / Orchestrator close-commit workflow / Telegram operator notifications
    revisit_trigger: Future close/commit, complete-chunk, operator daemon git commit, chunk autopilot, or Telegram notification workflow work removes or bypasses close-commit notification-contract evidence.
    next_action: Keep the close-commit notification path matrix and contract evidence tests current whenever close/commit or Telegram/operator notification paths change.
  - id: cfd-0022
    title: Runtime Action Panel needs a small Angular signal facade for route activation and live-state coordination
    category: architecture_debt
    severity: follow_up
    item_type: follow_up
    blocking: false
    status: open
    source_chunks:
      - chunk-000218-runtime-state-journal-stream-invalidation-consumer
      - chunk-000233-runtime-action-center-signal-facade
    source_sections:
      - Carry Forward
      - Other
    summary: >-
      Chunk 000218 exposed that the Runtime Action Panel can render its shell
      before the app shell has reliably triggered the singleton Admin Runtime
      Health state service load after guard-authenticated route activation. A
      narrow component-side load effect fixed the immediate proof, but route
      components should not become ad hoc coordinators for auth, socket
      invalidation, GraphQL refetch, cursor freshness, request coalescing, and
      diagnostics.
    evidence: >-
      During chunk 000218, the authenticated browser proof reached
      `/admin/health`, GraphQL returned `adminRuntimeHealth`, and the app
      shell/header rendered, but the `live-work-session` and `role-activity`
      sections did not appear until the health page component explicitly
      triggered the singleton state service load when admin auth was present.
      The final browser proof then passed through the Runtime State Journal
      consumer path with journal sequences `2339,2340`. This suggests the data
      ownership is correctly app-scoped, but activation/refetch orchestration
      should be centralized in a small feature facade rather than repeated
      page-local effects. The facade must preserve the 000218 live-currentness
      contract: Runtime journal sequence is the freshness cursor, GraphQL
      Runtime Health remains canonical UI truth, socket payloads are
      invalidation metadata only, and Runtime Health snapshot requests stay
      coalesced to avoid stampeding Runtime API.
      Chunk 000233 introduced `RuntimeActionCenterFacade` as the feature-level
      Angular signal coordinator for route activation, admin readiness,
      refresh/artifact actions, elapsed display ticks, and live diagnostics
      while preserving `AdminRuntimeHealthStateService` as the GraphQL/socket
      refetch owner.
    reason_to_track: Runtime Action Panel liveness depends on coordinated auth readiness, route activation, socket invalidation, GraphQL refetch, cursor freshness, and diagnostics. Keeping that coordination in scattered components risks stale or empty panels and page-specific fixes. Classic NgRx would add unnecessary boilerplate for this surface, so the preferred path is a lightweight Angular signals facade/store pattern.
    owner_surface: Angular Runtime Action Panel / Admin Runtime Health state service / app shell route activation
    revisit_trigger: Future Runtime Action Panel, app-shell navigation, socket invalidation, GraphQL state, admin auth guard, or frontend state-management work touches page activation or live refetch coordination.
    next_action: Keep Runtime Action Center route activation and user actions behind `RuntimeActionCenterFacade`; move additional page-local liveness coordination into the facade only when it simplifies components without making frontend state canonical. Revisit for closure after browser smoke proves the facade path under route reload/reconnect.
  - id: cfd-0023
    title: Browser proof channel PID 1 zombie debris and large smoke harness remain
    category: validation_debt
    severity: follow_up
    item_type: follow_up
    blocking: false
    status: open
    source_chunks:
      - chunk-000219-runtime-testing-channel-readiness-preflight
      - chunk-000234-runtime-test-channel-hardening-cfd-0023
      - chunk-000239-planned-restart-browser-proof
      - chunk-000240-unplanned-failure-browser-proof
      - chunk-000254-runtime-action-center-reliability-hardening-assertive-package
      - chunk-000257-operator-assistant-message-stream-correctness
      - chunk-000258-carry-forward-reconciliation-after-runtime-action-center-hardening
      - chunk-000280-pre-parallelism-readiness-summary
    source_sections:
      - Bad
      - Ugly
      - Carry Forward
    summary: >-
      The old broad Runtime test stall is no longer current repository truth:
      chunk 000234 added phase-narrowed bounded execution and chunk 000258
      reran `yarn --cwd ai/runtime test` successfully through completion in
      55.01 seconds. Browser proof preflight/cleanup is also hardened: active
      non-defunct Playwright-owned `headless_shell` leaks are cleaned before
      launch and fresh browser launch is the hard gate. Remaining debt is
      precise: unreapable PID 1 defunct `headless_shell` debris is an
      environment/container lifecycle limitation, and the broad
      `runtime-action-panel-browser-smoke.ts` harness remains intentionally
      large while reliability proof variants continue to accumulate.
    evidence: >-
      `node ai/runtime/dist/cli.js testing runtime-broad-tests --timeout-ms
      240000 --no-output-timeout-ms 120000 --json` produced
      `.tmp/testing-channel/reports/runtime-broad-tests-edda7ea7-c574-4be6-849a-c313c67c0898.json`
      with `classification=testing_channel_timeout`, and later narrowed output
      showed the last child phase as `stateSurfaces`. A killed earlier run left
      fixture leases for temporary manual-close chunks; they were cleared with
      `runtime lease-abort`. During chunk 000239, process inspection showed
      many zombie `headless_shell` processes and Playwright reported
      `browserType.launch: Target page, context or browser has been closed`
      with Chromium exiting via SIGSEGV. During chunk 000240, the first
      unplanned-failure browser proof recorded the Runtime journal event
      correctly, but the live backend had not yet loaded the new projection
      code, so the browser kept showing only Runtime API EPIPE service events.
      Restarting the backend through the typed supervisor made the same
      Playwright Test proof pass, proving the issue was stale service code and
      proof-harness opacity rather than a missing journal event. Chunk 000254
      added Runtime-owned browser-channel cleanup before app assertions:
      active non-defunct Playwright-owned `headless_shell` processes are
      terminated before launch, fresh browser launch remains the hard gate, and
      unreapable PID 1 defunct `headless_shell` debris is recorded as warning
      evidence rather than a false blocker. The browser proof for chunk 000254
      passed after typed Runtime API refresh, with
      `runningHeadlessShellCount=0`, `browserChannelCleanup.attempted=false`,
      and a warning for 386 unreapable defunct processes. Chunk 000257 browser
      proof also passed and reported 401 unreapable PID 1 defunct
      `headless_shell` processes while fresh launch and app assertions passed.
      Chunk 000258 reran the broad Runtime TypeScript test successfully:
      `yarn --cwd ai/runtime test` passed in 55.01 seconds, so the prior
      broad-test-stalls-after-stateSurfaces wording is stale.
      Chunk 000280 confirmed the Runtime build/reload freshness-gated test
      preflight as part of pre-parallelism readiness; no new browser proof
      channel blocker was introduced.
    reason_to_track: >-
      The testing channel and browser proof channel are now bounded and
      fail-fast, but PID 1 zombie debris can still confuse operators and the
      large Runtime Action Panel browser-smoke harness remains a maintenance
      hotspot for future reliability proof variants.
    owner_surface: Runtime testing channel / broad Runtime test suite / Runtime concurrency leases / Playwright browser proof channel
    revisit_trigger: Future Runtime testing, validation-runner, broad Runtime test, browser smoke, PWA proof, lease cleanup, or fail-fast proof-mode work touches test execution.
    next_action: Keep `ai/commands/runtime-action-panel-browser-smoke.mjs` as the bounded canonical Action Panel browser proof facade over Runtime-owned proof variants. Do not block fresh browser proof solely on old unreapable PID 1 zombie debris when fresh launch succeeds. Revisit only if active Playwright-owned process leaks accumulate again, Chromium fresh launch fails, or the large browser-smoke harness blocks safe maintenance; a true fix for PID 1 defunct debris requires container init/reaper lifecycle work rather than repo-level cleanup.
  - id: cfd-0024
    title: Runtime API autonomous killed-process resurrection proof remains
    category: runtime_debt
    severity: follow_up
    item_type: follow_up
    blocking: false
    status: open
    source_chunks:
      - chunk-000226-action-center-md-browser-fail-log-navigation-cleanup
      - chunk-000229-service-fail-log-and-bounded-retention
      - chunk-000232-service-downtime-recovery-proof
      - chunk-000239-planned-restart-browser-proof
      - chunk-000240-unplanned-failure-browser-proof
      - chunk-000242-final-service-downtime-recovery-summary
      - chunk-000254-runtime-action-center-reliability-hardening-assertive-package
      - chunk-000255-fully-retire-legacy-telegram-shell-dispatch
      - chunk-000285-overnight-runtime-execution-policy-package-summary
      - chunk-000297-runtime-api-killed-process-resurrection-proof-if-safe
      - chunk-000300-runtime-api-watchdog-safe-resurrection-design-cfd-0024
    source_sections:
      - Other
    summary: >-
      During chunk 000226 review, the backend health endpoint was reachable but
      the frontend dev server was unreachable, and the operator observed service
      downtime without a clear planned/failure notification. Service downtime
      must be represented as planned, recovering, recovered, failed, or unknown
      with durable evidence.
    evidence: >-
      `http://127.0.0.1:3720/health` returned 200 while
      `http://127.0.0.1:4220` failed. A Runtime supervisor `dev_server_restart`
      request restored the frontend earlier in chunk 000226, but the
      operator-facing notification path for that downtime was not proven in the
      UI. During chunk 000229, `runtime-services` initially listed
      operator-daemon, runtime-supervisor, approved-action-dispatcher,
      telegram-bridge, and runtime-api, but did not include the frontend dev
      server; browser smoke initially failed because nothing listened on
      `127.0.0.1:4220`. Chunk 000229 added a `frontend-dev-server` service row
      with a bounded HTTP probe and made supervisor dev-server restarts require
      a sustained reachability check. During chunk 000230 final validation, an
      Angular build was killed under memory pressure while stale/orphaned
      backend watch processes remained after a supervised backend restart; local
      severe-recovery cleanup was needed to pass validation. Automatic recovery,
      stale process-tree reaping, and a prominent browser-visible
      planned/unplanned outage notification remained open. Chunk 000232 added
      typed supervisor service-event progress for
      `service.restart_planned`, `service.restart_in_progress`,
      `service.restart_completed`, and `service.restart_failed`; projected
      supervisor progress into the backend Runtime service log; added
      dev-server process-tree cleanup for pid-file roots and stale known
      backend/frontend dev-server command roots; and live-proved a supervised
      frontend `dev_server_restart` request `9c0ecb97` with planned restart ack
      HTTP 201, frontend stop/start evidence, and restored HTTP 200 reachability.
      During chunk 000238 startup, the operator observed that Runtime appeared
      down and was not resurrected. A direct Runtime Health snapshot query
      returned failed/null while the standalone typed supervisor reported
      `status: running`, no pending/running requests, and no automatic recovery
      in progress. This makes the resurrection gap concrete: supervisor
      liveness alone does not currently guarantee Runtime API recovery or
      browser-visible recovery progress. Chunk 000240 added Runtime State
      Journal `service_status` events to the backend Runtime service log
      projection and proved a controlled local/dev unplanned frontend
      failure/recovery marker through the browser: Runtime State Journal event
      to journal-consumer invalidation to GraphQL refetch to Runtime Action
      Panel service-log render. The proof deliberately did not kill arbitrary
      processes; real crash simulation and toast semantics remain for the next
      service-recovery/toast chunks. Chunk 000242 proved the real planned
      Runtime API restart path end to end in the authenticated browser through
      typed supervisor request `fd488d0f`: the browser reached the real
      `/admin/health` route, observed `service.restart_planned` and
      `service.restart_in_progress`, the supervisor stopped and restarted the
      Runtime API process tree, Runtime API recovered, GraphQL service-log
      projection included `service.restart_completed`, and the browser updated
      without manual reload. Chunk 000242 also repaired the raw Runtime
      browser-smoke harness so synchronous Runtime CLI read-model refreshes no
      longer block Playwright progress, and command-level browser proof timeouts
      now emit `testing_channel_timeout` with durable report evidence instead
      of hanging silently. Chunk 000254 re-ran the typed planned Runtime API
      restart/browser proof after a stale Runtime daemon build mismatch,
      recovered the daemon through typed supervisor request `5ec126c3`, and
      proved the Action Panel browser path still renders planned restart,
      in-progress restart, and completion events from GraphQL service-log truth
      without manual reload. Chunk 000254 did not claim safe real unplanned
      killed-process resurrection: inspection confirmed the typed supervisor
      handles requested recovery actions, but does not yet own an autonomous
      watchdog policy that observes unsolicited Runtime API death, decides
      whether immediate resurrection is allowed, records that intent, and
      starts recovery without operator/frontend inference. During chunk 000255,
      after Runtime TypeScript source changed and `yarn --cwd ai/runtime build`
      passed, the typed supervisor `runtime_api_build_reload` action returned
      success but did not replace the stale running `runtime-daemon` process;
      `telegram.operatorSurface` continued serving the old TSV-based validator
      until the stale daemon process was killed and the daemon was started
      manually from current dist. This is concrete evidence that successful
      planned reload reporting can diverge from actual Runtime API generation
      replacement. Chunk 000261 added `testing service-resurrection-smoke`,
      which safely killed the supervised local/dev frontend dev-server process
      tree, recorded `service.failure_unplanned`, `service.recovery_started`,
      and `service.recovered_unplanned` Runtime State Journal evidence with
      `immediate_resurrection_allowed: true`, used the typed Runtime supervisor
      to restart the service, refreshed Runtime Health, and wrote
      `ai/reports/report-000261-service-resurrection-smoke.md`. The browser
      proof `ai/reports/report-000261-runtime-action-panel-resurrection-browser-proof.md`
      then proved those unplanned failure/recovery events rendered in the
      Runtime Action Panel through GraphQL/refetch without manual reload.
    reason_to_track: >-
      Runtime Action Panel reliability depends on services failing visibly and
      recoveries being distinguishable from silent outages. Planned Runtime API
      restart, controlled local/dev unplanned failure visibility, and safe real
      killed-process local/dev frontend resurrection are now browser-proven; the
      remaining gap is unsolicited Runtime API killed-process detection plus an
      autonomous Runtime-owned resurrection watchdog policy/proof.
    owner_surface: Runtime supervisor / service-status projection / Action Panel service notifications
    revisit_trigger: Future service restart, frontend dev server, backend API, Runtime supervisor, crash notification, or Action Panel service-status work touches planned/failure notification behavior.
    next_action: >-
      Keep the chunk 000261 safe local/dev frontend resurrection smoke and
      browser proof as the baseline killed-process regression. The remaining
      scope is narrower: implement a Runtime API watchdog policy that observes
      unsolicited Runtime API daemon death without frontend inference, records
      planned/manual suppression state, immediate_resurrection_allowed,
      observed failure, recovery started/completed/failed, and concrete next
      action in Runtime-owned service status/journal evidence, then proves an
      autonomous Runtime API resurrection in the browser. Keep
      `runtime_api_build_reload` generation replacement checks as the planned
      restart baseline regression. Chunk 000297 confirmed this remains unsafe
      to prove by killing the Runtime API today: the live daemon is identifiable
      from `.tmp/runtime-api/pid` and typed planned restart actions exist, but
      the supervisor loop only executes queued requests and does not yet watch
      Runtime API liveness, record an unsolicited death policy decision, or
      autonomously enqueue recovery. Chunk 000300 added the non-destructive
      Runtime-owned watchdog prerequisite: `runtimeApiWatchdogPolicy`, typed
      fail-log evidence, planned/manual suppression, heartbeat/pid ownership
      inspection, cooldown/circuit-breaker fields, Runtime Health service
      projection fields, an API export, and the
      `supervisor runtime-api-watchdog-policy` CLI. The remaining scope is now
      the autonomous supervisor loop plus browser-visible killed-process proof,
      not the policy/projection design.
  - id: cfd-0025
    title: Runtime API write EPIPE error burst root cause remains
    category: runtime_debt
    severity: follow_up
    item_type: follow_up
    blocking: false
    status: resolved
    source_chunks:
      - chunk-000170-admin-ui-consistency-operator-ergonomics-crosscheck
      - chunk-000194-runtime-service-freshness-controller-and-operator-notification
      - chunk-000221-typed-runtime-supervisor-node-typescript-migration
      - chunk-000240-unplanned-failure-browser-proof
      - chunk-000254-runtime-action-center-reliability-hardening-assertive-package
      - chunk-000285-overnight-runtime-execution-policy-package-summary
    source_sections:
      - Carry Forward
      - Bad
      - Ugly
    summary: >-
      Runtime API Unix-socket client disconnect writes are now classified as
      benign `client_disconnect_write_aborted` diagnostics with request/socket
      correlation instead of severe unclassified Runtime API transport errors.
    evidence: >-
      During chunk 000240, `.tmp/runtime-api/errors.jsonl` contained repeated
      `runtime-api-unix-socket` records with `phase=write_response`,
      `code=EPIPE`, and `message=write EPIPE` from timestamps including
      2026-05-18T09:06:50.180Z, 2026-05-18T09:13:25.363Z, and
      2026-05-18T09:14:23.571Z. Runtime Health service-log projection showed
      the same errors, proving observability but not root-cause elimination.
      Earlier chunks 000170, 000194, and 000221 hardened transport containment
      so these errors do not silently crash the daemon, but operator review
      still saw noisy repeated entries. Chunk 000254 changed the Unix-socket
      transport so response-write `EPIPE`/`ECONNRESET` records are classified
      as `client_disconnect_write_aborted`, severity `info`, include
      `socket_id`, `request_id`, `method`, `request_started_at`,
      `response_write_phase`, and `client_disconnected_first`, and preserve
      real transport errors as `runtime_api_transport_error`. The daemon test
      now opens Runtime API requests and deliberately disconnects before the
      response, asserting that matching write-abort records are classified as
      benign client disconnects with method/request correlation.
    reason_to_track: >-
      A high-volume EPIPE loop can obscure more important service events,
      degrade operator trust, and may indicate clients timing out or closing
      before expensive Runtime responses finish.
    owner_surface: Runtime API Unix-socket transport / Runtime client timeouts / Runtime Health polling
    revisit_trigger: >-
      Future Runtime API transport, health snapshot performance, browser smoke,
      service fail log, or materialized read-model work touches client request
      lifetimes or Runtime response writing.
    next_action: >-
      Reopen only if response-write client disconnects again appear as severe
      unclassified Runtime API failures, or if a real transport failure is
      hidden by the benign disconnect classification.
  - id: cfd-0026
    title: Operator and assistant message stream capture is Runtime-owned and browser-proven
    category: operator_ux_debt
    severity: advisory
    item_type: advisory
    blocking: false
    status: resolved
    source_chunks:
      - chunk-000244-action-panel-toast-message-state-proof
      - chunk-000245-operator-assistant-message-stream-health-window
      - chunk-000246-deterministic-chat-runner-message-capture
      - chunk-000249-operator-message-retention-policy-unification
      - chunk-000250-operator-message-stream-canonical-policy
      - chunk-000257-operator-assistant-message-stream-correctness
    source_sections:
      - Carry Forward
      - Other
    summary: >-
      Operator prompts, assistant inline answers, and assistant work updates are
      now captured through repository-controlled Runtime sources and displayed
      as a bounded frontend-visible message log. The stream imports operator
      prompts from Codex history, assistant output/work-update bodies from
      Codex SQLite logs, direct Runtime message records, progress notes, and
      existing operator question/answer files. Runtime/GraphQL remains
      canonical UI truth, Socket.IO remains invalidation-only, and browser proof
      verifies readable bodies without manual reload.
    evidence: >-
      During chunk 000244, the operator clarified that assistant work-update
      messages such as "I am going to..." are interesting as future operational
      messages, and asked that operator prompts, assistant answers, and work
      updates be captured in backend storage and exposed in the frontend.
      During chunk 000245, the operator verified that existing persisted
      Runtime/progress records could show in the Health page, but the current
      live prompt/answer exchange was not visible because no producer captures
      ChatGPT platform messages into the backend-owned stream.
      During chunk 000246, repository search found Remote Dev Console as a
      backend-owned prompt boundary and Codex I/O bridge as tmux observability
      only. Remote Dev Console prompt queue and tmux input submissions now write
      redacted `operator_prompt` records into the bounded stream. No repository
      hook was found for automatic capture of this API-hosted ChatGPT exchange
      or assistant inline answers.
      During chunk 000249, direct GraphQL query to `adminRuntimeHealth`
      returned current `operatorAssistantMessages`, including Runtime progress
      note bodies and the Playwright passive message proof entry
      `pw-action-panel-mpb9teja`. A browser probe through `/admin/health`
      showed the same current Work Updates after expanding the collapsed group.
      The latest direct prompt/answer records in the JSONL stream still stopped
      at the earlier `codex-chat` entries because the outer ChatGPT runner had
      not produced records for the current conversation.
      During chunk 000250, repository standards were updated to make
      `runtime message-record` the canonical repo-controlled producer path for
      operationally relevant prompts, assistant inline answers, and assistant
      work updates. During chunk 000254, the operator reported that hard
      refresh/pull refresh still showed stale prompt/answer records and many
      title/header-only rows. Chunk 000257 then implemented the missing
      deterministic producer and freshness paths: Runtime imports operator
      prompts from `/home/node/.codex/history.jsonl`, imports assistant
      `output_text` bodies from `/home/node/.codex/logs_2.sqlite` using
      Node/TypeScript `node:sqlite`, runs daemon-side mtime-based bounded
      auto-sync, de-dupes stable IDs, redacts, emits
      `operator_assistant_messages` journal events, and makes the backend
      journal consumer refetch the Runtime Health read model for already-open
      browsers. The final browser proof
      `ai/reports/report-000257-operator-assistant-message-stream-browser-proof-4.md`
      passed and explicitly checked that fresh operator prompt, assistant
      answer, and assistant work update records were written through Runtime,
      Codex history and assistant-log sync sources were imported through
      Runtime, fresh message bodies rendered in the Health page without reload,
      and GraphQL `operatorAssistantMessages` contained fresh bodies. The proof
      sample includes readable work-update and legacy progress-note bodies,
      including `Message: CFD-relevant detail...` and
      `Message: Routine progress note...`.
    reason_to_track: >-
      Resolved history. Reopen only if current operator prompts, assistant
      answers, or assistant work updates again fail to appear from Runtime
      durable sources with readable bodies in GraphQL/Health page after daemon
      sync and browser invalidation.
    owner_surface: Runtime Action Panel / backend activity message stream / operator context
    revisit_trigger: >-
      Future Runtime Action Panel message log, live prompt capture, assistant
      response capture, orchestration summary, or app-shell activity stream work
      touches operator-visible context.
    next_action: >-
      Keep Runtime Codex durable-source ingestion, direct `runtime
      message-record`, bounded retention, redaction, and
      `operator_assistant_messages` invalidation covered by regression tests
      and browser proof. Reopen with exact evidence if live Codex prompt/answer
      capture regresses or if a future runner no longer writes the durable
      history/log sources consumed by Runtime.
  - id: cfd-0027
    title: Admin Runtime Health page remains a large frontend aggregation component
    category: architecture_debt
    severity: advisory
    item_type: advisory
    blocking: false
    status: open
    source_chunks:
      - chunk-000251-operator-message-stream-health-ui-freshness
      - chunk-000252-frontend-runtime-ui-architecture-best-practice-enforcement
    source_sections:
      - Policy Enforcement
      - Carry Forward
    summary: >-
      The Admin Runtime Health page now uses a computed view model for
      operator/assistant message rows, but the page component is still a large
      aggregation component that mixes many presentation helpers for Runtime
      Action Center sections. This is accepted short-term to avoid a broad UI
      rewrite during architecture enforcement.
    evidence: >-
      The frontend architecture report added in chunk 000252 scans
      `apps/frontend/src/app` and accepts
      `apps/frontend/src/app/features/admin-health/components/admin-runtime-health-page.component.ts`
      as a known large page component while warning that future semantic data
      flow should move into feature facades, computed view models, or focused
      child components. Chunk 000251 fixed the current operator-message stream
      issue narrowly without splitting the entire page. Chunk 000262 reran the
      frontend architecture report and recorded
      `ai/reports/report-000262-frontend-architecture-current.json`: status
      passed in advisory mode, 8 findings, 7 active advisory findings, and the
      accepted Admin Runtime Health large page exception.
    reason_to_track: >-
      Large page components are more likely to accumulate data orchestration,
      template method mappings, and Runtime-specific presentation coupling
      unless future UI chunks keep moving semantic view models into services,
      facades, or focused child components.
    owner_surface: Admin Runtime Health frontend / Runtime Action Center UI
    revisit_trigger: >-
      Future Admin Runtime Health, Runtime Action Center, workflow artifact,
      service-status, socket diagnostics, or operator message UI work touches
      the page component or adds new semantic sections.
    next_action: >-
      When the next substantial Admin Runtime Health UI change occurs, extract
      the touched semantic section into a focused computed view model, facade,
      or child component instead of adding more page-local orchestration.
  - id: cfd-0028
    title: Backend and Runtime architecture advisory findings need targeted boundary cleanup
    category: architecture_debt
    severity: advisory
    item_type: advisory
    blocking: false
    status: open
    source_chunks:
      - chunk-000253-backend-node-nestjs-architecture-best-practice-enforcement
      - chunk-000281-architecture-drift-obsolete-path-detection-gate
    source_sections:
      - Policy Enforcement
      - Carry Forward
    summary: >-
      The backend architecture report added in chunk 000253 makes layered
      backend/Runtime boundary risks visible. It accepts several known large
      hotspots short-term and reports advisory findings for shell execution,
      direct environment access, and Runtime `.tmp` state reads that should be
      moved behind typed adapters when those areas are next touched.
    evidence: >-
      `ai/commands/backend-architecture-report.sh --json` scans
      `apps/backend/src` and `ai/runtime/src`. Its first run scanned 127
      TypeScript files, passed in advisory mode, and reported accepted large
      hotspots for
      `apps/backend/src/admin-runtime-health/services/admin-runtime-health.service.ts`,
      its large spec, `ai/runtime/src/api/runtime.ts`,
      `ai/runtime/src/cli.ts`, and
      `ai/runtime/src/modules/health/health-snapshot.ts`, plus active advisory
      findings for backend shell execution, direct Runtime `.tmp` references,
      direct env reads, and the large Runtime supervisor module. These findings
      are evidence for future targeted cleanup, not blockers for introducing
      the enforcement mechanism. Chunk 000262 reran the backend/runtime
      architecture report and recorded
      `ai/reports/report-000262-backend-runtime-architecture-current.json`:
      status passed in advisory mode, 46 findings, 40 active advisory findings,
      and 6 accepted hotspots. This chunk touched Runtime Executor, consultant
      checkpoint, and state-surface registry code; local journal-producer
      boundary cleanup was implemented there, while broader shell/env/tmp and
      large-module findings remain targeted advisory follow-up.
      Chunk 000281 added a Runtime-owned architecture drift report and recorded
      `ai/reports/report-000281-architecture-drift.yaml`: status advisory, 72
      findings, 0 high-confidence findings, and 23 backend
      transport/domain/projection mixing findings. These are carried forward as
      targeted advisory cleanup rather than blockers.
    reason_to_track: >-
      Without a tracked follow-up, future backend/Runtime work can continue
      adding orchestration to large services or leaking raw IO/env/shell access
      through request/projection paths even though the standard now forbids new
      violations.
    owner_surface: Backend / Runtime Node / Admin Runtime Health / Runtime Action Center service projection
    revisit_trigger: >-
      Future Admin Runtime Health backend, Runtime API transport, Runtime CLI,
      Runtime Health snapshot, Runtime supervisor, Socket.IO diagnostics,
      service-status projection, or backend Runtime bridge work touches one of
      the reported files or adds new shell/env/tmp access.
    next_action: >-
      Treat the backend architecture report as the review entry point for the
      next touched backend/Runtime area. Fix narrow findings immediately when
      local and safe; otherwise split the touched hotspot into typed adapters,
      projection helpers, or Runtime modules under a focused chunk with tests.
  - id: cfd-0029
    title: Codex compaction must preserve autonomous workflow continuation
    category: operator_ux_debt
    severity: follow_up
    item_type: follow_up
    blocking: false
    status: open
    source_chunks:
      - chunk-000270-minimum-downtime-runtime-api-reload-path
      - chunk-000280-pre-parallelism-readiness-summary
      - chunk-000287-hosted-codex-activity-visibility-unregistered-work-diagnostic
      - chunk-000293-role-work-visibility-e2e-proof-harness
    source_sections:
      - Carry Forward
      - Other
    summary: >-
      During the autonomous overnight Runtime execution package, context
      compaction interrupted visible progress even though the operator had
      repeatedly instructed Codex to continue through all backlog chunks. The
      compacted summary preserved enough state to resume, but there is no
      Runtime-owned resume guard that automatically detects "autonomous package
      still active" after compaction and immediately re-enters the registered
      work loop without operator prompting. The same follow-up should audit the
      current work-registration workflows, schemas, states, and role/activity
      projections for obsolete or unused pieces introduced by earlier
      iterations, then retire or tighten anything that no longer serves a clear
      Runtime-owned purpose.
    evidence: >-
      On 2026-05-19 the active chunk was
      `ai/chunks/active/chunk-000270-minimum-downtime-runtime-api-reload-path.md`
      and Runtime Health showed Developer work active, but the operator had to
      ask why execution stopped after compaction. The failure was not a chunk
      lifecycle or Runtime Health failure; it was a Codex/session continuity
      gap between context compaction and the next autonomous action. During
      chunk 000270 follow-up, Runtime-owned wrapper commands such as typed
      supervisor reloads, Runtime browser smoke, backend/frontend spec runners,
      summary validation, and QA review registered work-session/work-step
      evidence, but direct hosted Codex tool actions such as `apply_patch` and
      raw tool invocations not mediated by verified project-local Codex hook
      configuration did not automatically appear as active work in the Action
      Panel. Local Codex reports hooks available, but project-local hook event
      wiring remains unverified, so command/tool visibility is not yet complete
      for the hosted runner. During chunk 000274, the operator observed no
      active work in the Action Panel while Codex executed a direct `find`
      tool command. Because `find` is a meaningful hosted tool action that
      should trigger `PreToolUse` if project-local hooks were active, this is
      concrete evidence that the current runner/tool path is bypassing the
      project hook adapter or that hook invocation is not wired into the active
      session. Follow-up inspection found `/workspace/.codex` has no
      `hooks.json` or inline hook config, `/home/node/.codex/config.toml` only
      marks `/workspace` trusted, and the local Codex log records direct
      `ToolCall: exec_command` entries with no preceding `PreToolUse` or
      `codex-hook` event. Official Codex hook documentation confirms hook
      sources must be configured in user/project hook files and that
      `PreToolUse`/`PostToolUse` interception is incomplete for the newer
      `unified_exec` shell mechanism. A project hook source was then added and
      manually smoke-tested; supported `PreToolUse` for a `find` command now
      registers a Codex diagnosis step, but the operator observed it visible
      for only about three seconds while the turn continued. That shows a
      second gap: per-tool hook pulses need reliable `PostToolUse` heartbeats
      and/or a parent Orchestrator/Developer session that remains active across
      a tool sequence. During chunk 000271, typed supervisor wrapper work could
      temporarily displace the active Developer work session; the
      interrupted-session restore path exists for automatic work, but the
      operator still observed gaps while the read model/UI caught up. The same
      chunk also observed that operator/assistant notes can appear to regress
      to older rows when a lagging health snapshot is rendered during journal
      cursor retry; a narrow frontend guard now preserves fresher message rows,
      but the broader message-sync/read-model freshness contract still needs
      proof under full browser/live-update conditions. During chunk 000275,
      direct probes confirmed hosted `exec_command` and `apply_patch` tool
      calls did not create Runtime work-history records even though
      `.codex/hooks.json` existed. Local Codex logs showed this runner records
      tool names as `exec_command` and `apply_patch`; the project hook matcher
      only covered `Bash|apply_patch|Edit|Write|mcp__.*`, so shell tool calls
      were not matched. The matcher was expanded to include `exec_command`,
      `functions.exec_command`, `write_stdin`, `functions.write_stdin`,
      `functions.apply_patch`, and `multi_tool_use.parallel`. Adapter
      tests/control probes also found that filesystem-write hooks could be
      absorbed by an unrelated fresh parent session and lose file-change detail;
      the adapter now creates a dedicated Developer coding step for filesystem
      writes. Read-only hook steps could inherit `file_change_expected=true`
      from a prior write parent; that metadata was corrected. Remaining proof
      still must verify that the hosted runner invokes the project hook after
      matcher changes, because explicit bridge invocation works but prior
      hosted probes did not. Chunk 000280 confirmed that autonomous
      continuation through the ordered backlog remains the package policy,
      while final chunk 000285 must stop before commit unless newer operator
      authority permits it. Chunk 000293 added an end-to-end browser proof
      that renders a bounded hosted Codex diagnostic as "Unregistered hosted
      Codex activity detected" when no fresh registered Runtime work is active.
      The diagnostic remains `acceptedAsWork: false` and does not satisfy
      work-registration evidence. The same proof verifies registered work takes
      precedence while parent/foreground-child work is active. Chunk 000295
      moved live-work display classification into the Runtime/backend
      projection so hosted Codex diagnostics render through normalized
      `unregistered_activity_diagnostic` items with `trust: diagnostic_only`,
      category/tool/reason fields, and an explicit "not registered" warning
      instead of frontend-local source-action inference.
    reason_to_track: >-
      Autonomous package execution should survive context compaction without
      changing the commanded workflow, otherwise the Action Panel can correctly
      show registered work while actual Codex execution waits for a new user
      nudge.
    owner_surface: Codex hook adapter / Runtime work registration / orchestration resume policy
    revisit_trigger: >-
      Future Codex hook, autonomous orchestration, work-session resume,
      context-compaction, hosted Codex tool/log parsing fallback, or Action
      Panel active-work visibility changes touch session continuation behavior.
    next_action: >-
      Add a Runtime/Codex resume guard that records an autonomous package
      continuation token in the existing work-registration model and verifies
      after compaction or Stop/Start that active autonomous chunks resume or are
      explicitly terminalized as blocked/stale. As part of that chunk, inspect
      work-registration workflows, schemas, role/activity states, hook adapter
      states, and Action Panel projections for unused, obsolete, or overly loose
      states left by previous designs; remove or tighten them where local and
      safe, and record exact remaining compatibility-only states if any must
      stay. Add explicit parent/return-role semantics for automatic wrapper
      sessions so Runtime Supervisor, validation, QA, and browser-proof work
      can be displayed without erasing the owning Developer/Orchestrator
      context. Prove that role cards do not disappear during wrapper start,
      completion, read-model refresh, and browser refetch. Keep deterministic
      capture for hosted Codex tool actions that bypass project-local hooks as a
      visibility diagnostic in Runtime Health, not as accepted work. Chunks
      000287 and 000295 added that bounded diagnostic as visibility-only
      `hosted_codex_activity` plus normalized
      `unregistered_activity_diagnostic` display items; they do not satisfy
      work-registration requirements. A future enforcement chunk still needs an
      end-to-end Action Panel proof where a direct hosted file-inspection
      command, a patch/edit command, a validation wrapper, and a QA command all
      produce visible registered work or a clear registration violation without
      manual work registration. The proof must show work stays visible
      throughout a multi-tool orchestration sequence, not only for a short
      `PreToolUse` pulse. Include
      message-stream freshness proof so lagging health snapshots cannot regress
      operator/assistant notes after a newer note has been rendered. Keep
      close-gate validation as hard enforcement, and do not introduce a second
      work-registration store.
  - id: cfd-0030
    title: QA should include deterministic and randomized end-to-end behavior proof
    category: validation_debt
    severity: follow_up
    item_type: follow_up
    blocking: false
    status: resolved
    source_chunks:
      - chunk-000270-minimum-downtime-runtime-api-reload-path
      - chunk-000272-qa-test-requirement-resolver-behavior-proof-gate
      - chunk-000273-research-gated-system-mechanism-policy
      - chunk-000274-runtime-action-panel-connection-recovery-state-model
      - chunk-000275-deterministic-adversarial-state-machine-tests
      - chunk-000276-qa-executor-evidence-enforcement
      - chunk-000281-architecture-drift-obsolete-path-detection-gate
      - chunk-000282-final-validation-cfd-0030-reconciliation
    source_sections:
      - Carry Forward
      - Validation
    summary: >-
      Resolved: Runtime QA now has a queryable required-evidence resolver,
      research/design checkpoint policy, concrete Action Panel
      connection/recovery state model, deterministic and forbidden transition
      tests, seeded adversarial state-machine tests, browser proof requirements,
      final clean-pass evidence, QA executor evidence enforcement, and an
      architecture drift report surface. Future operator-facing Runtime chunks
      must use the resolver instead of relying on prose-only QA memory.
    evidence: >-
      During chunk 000270, deterministic planned-restart and
      service-resurrection browser proof caught unstable planned downtime
      indication. Chunk 000271 exposed that stale restored/recovery UI timing
      could briefly mask a backend-owned outage after frontend resurrection.
      Chunks 000272-000276 closed the systemic QA/process gap by adding the
      Runtime-owned QA required-evidence resolver, research-gated mechanism
      policy, canonical Action Panel connection/recovery state model,
      deterministic/forbidden/seeded adversarial state-machine tests, final
      clean-pass rule, typed QA evidence enforcement, and browser proof
      requirements. Chunk 000274 proved the user-visible path with
      `report-000274-runtime-action-panel-connection-recovery-browser-proof.md`,
      covering planned restart, unplanned frontend/backend recovery, restored
      toast clearing, signed-out block, QA role evidence, work-role matrix, and
      Codex hook work registration in one integrated browser proof. Chunk 000275
      expanded deterministic/adversarial state-machine tests and recorded the
      final integrated browser proof. Chunk 000281 added architecture drift
      detection with 0 high-confidence findings in
      `report-000281-architecture-drift.yaml`.
    reason_to_track: >-
      A feature can pass deterministic validation while still failing under
      realistic ordering or timing variation. Operator-facing Runtime behavior
      should prove the intended user experience, not only individual command
      success.
    owner_surface: QA executor / browser smoke harness / Runtime Action Panel proof / validation runner
    revisit_trigger: >-
      Reopen if a stateful/live UI/service chunk can pass QA without the
      resolver-required evidence, if browser-visible Runtime behavior is
      accepted without browser/system proof, if a future chunk bypasses final
      clean-pass evidence for interdependent scenarios without a
      research-backed equivalent, or if duplicate state-machine/reconnect
      paths regain high-confidence drift status.
    next_action: >-
      Keep the Runtime QA required-evidence resolver canonical for future
      chunks. Use declared QA categories and mechanism metadata so
      stateful/live/service chunks require research/design checkpoint, state
      model, deterministic and forbidden transition tests, seeded adversarial
      tests where practical, browser proof for user-visible behavior,
      architecture drift checks, and one final uninterrupted clean pass after
      individual proof cases are fixed. Do not replace targeted unit/spec
      validation; keep behavior proof as additional required evidence for
      behaviorally rich or operator-facing changes.
  - id: cfd-0031
    title: Web console paste can duplicate command submission
    category: operator_ux_debt
    severity: follow_up
    item_type: follow_up
    blocking: false
    status: open
    source_chunks:
      - chunk-000270-minimum-downtime-runtime-api-reload-path
    source_sections:
      - Carry Forward
      - Other
    summary: >-
      The browser/web console sometimes appears to paste or submit a command
      two or three times from a single operator action.
    evidence: >-
      During chunk 000270, the operator reported that using the web console
      sometimes pastes commands two or three times. This was not investigated
      inside the Runtime restart/recovery chunk because it is a distinct input
      handling surface.
    reason_to_track: >-
      Duplicate command paste/submit can trigger repeated operator actions,
      create confusing Runtime work evidence, or increase risk around
      authority-sensitive commands if the console does not debounce or
      idempotently identify submissions.
    owner_surface: Web console / operator command input / frontend input handling
    revisit_trigger: >-
      Future web console, operator command entry, terminal input, command
      submission, keyboard/paste handling, or Runtime Action Panel console work
      touches command input behavior.
    next_action: >-
      Add a focused browser/input test that pastes and submits commands through
      the web console using clipboard, keyboard, and direct input events;
      verify exactly one command buffer update and one submission are produced.
      If duplication reproduces, fix paste/keydown/input composition handling
      with debouncing or submission idempotency at the UI boundary, and keep
      backend/Runtime command execution idempotency as a separate safety layer.
  - id: cfd-0032
    title: Runtime-owned backlog activation path is missing
    category: governance_debt
    severity: follow_up
    item_type: follow_up
    blocking: false
    status: open
    source_chunks:
      - chunk-000271-supervisor-auto-resurrection-policy-unplanned-failure
      - chunk-000287-hosted-codex-activity-visibility-unregistered-work-diagnostic
      - chunk-000292-runtime-owned-backlog-activation-terminal-archive
      - chunk-000294-real-simulated-workflow-run
    source_sections:
      - Carry Forward
      - Policy Enforcement
    summary: >-
      The Runtime Executor lifecycle transition model can validate Active to
      Ready for Human Review, Approved, Closed, and Committed, but it does not
      currently provide a normal Backlog to Active activation transition or a
      canonical archive step that clears the active chunk slot after a deemed
      autonomous Committed transition. The only available backlog-to-active
      mover is `ai/commands/activate-chunk.sh`, which is correctly hard-guarded
      as an emergency legacy lifecycle shell path. The state label "Ready for
      Human Review" is also mode-confusing: in autopilot it means ready for the
      configured review authority, not necessarily a human stop.
    evidence: >-
      During chunk 000271 activation, `node ai/runtime/dist/cli.js
      executor-transition --chunk 000271 --to Active --recommendation continue
      --mode live --json` was refused because Backlog -> Active is not allowed
      by `ai/governance/registries/chunk-lifecycle.yaml`. Inspecting
      `ai/commands/activate-chunk.sh` showed it exits unless
      `RUNTIME_ALLOW_LEGACY_LIFECYCLE_SHELL=true` is set and warns that normal
      workflow must use Runtime-owned chunk planning/executor paths. Because
      the active package already contained approved backlog chunks and the
      operator had explicitly authorized autonomous continuation through all
      backlog chunks, chunk 000271 used the guarded compatibility activation
      facade. During chunk 000272, Runtime Executor successfully transitioned
      Ready for Human Review -> Approved -> Closed -> Committed in deemed
      autonomous mode, but the chunk file remained in `ai/chunks/active`,
      requiring a compatibility archive to free the active slot for the next
      backlog chunk. That compatibility use should not become the normal path.
      `ai/standards/operator-notifications.md` also requires autonomous/deemed
      completion to emit non-actionable chunk completed/approved/committed
      Telegram/operator notices; autonomous authority removes the approval
      question, not the mandatory progress notification. During chunk 000287,
      the Runtime Executor transition state reached Committed, but no new git
      commit was created and the chunk file remained in `ai/chunks/active`;
      dispatcher summary showed no pending approved action to consume. This
      required explicit recovery through the compatibility archive and git
      commit path after validation had passed. Chunk 000292 added typed Runtime
      Executor `activateChunk` and `archiveChunk` procedures, CLI commands,
      socket/API methods, work registration wrappers, state-journal events, and
      runtime-concurrency singleton entries for `chunk_activation` and
      `chunk_terminal_archive`. The Runtime intrinsic test now includes an
      isolated `runtimeOwnedChunkActivationArchive` phase proving dependency
      validation, Backlog -> Active file movement, status/evidence update,
      Committed active chunk terminal archive, completed timestamp update, and
      active-slot clearing without shell helpers. Remaining closure depends on
      the real simulated workflow/browser proof chunks using those typed paths
      in the live repository workflow. Chunk 000294 then activated the live
      simulated workflow through `executor-activate-chunk`, made a harmless
      standalone ODE solver/visualizer fixture change, ran Runtime Action Panel
      browser proof and fixture browser proof, transitioned through the typed
      Runtime Executor lifecycle, and archived the terminal active chunk with
      `executor-archive-chunk` without using the legacy shell lifecycle helpers.
    reason_to_track: >-
      This item is resolved for normal Runtime-owned Backlog -> Active
      activation and terminal active-chunk archive. It remains in the registry
      as regression guidance because lifecycle authority is sensitive and
      shell compatibility helpers must not return to normal workflow.
    owner_surface: Runtime Executor lifecycle transitions / chunk activation / orchestration backlog scheduler
    revisit_trigger: >-
      Future chunk activation, backlog scheduler, autonomous package
      continuation, chunk planner output activation, lifecycle registry,
      ready/review state naming, autopilot mode policy, archive/commit
      completion, or shell lifecycle hard-guard work touches Draft/Backlog to
      Active or terminal archive semantics.
    next_action: >-
      Reopen only if normal backlog activation or terminal active-chunk archive
      requires `activate-chunk.sh`, `complete-chunk.sh`, manual file movement,
      or another non-Runtime authority path. Remaining optional naming cleanup
      is to alias "Ready for Human Review" to a mode-aware "Ready for Review"
      concept where human/manual vs autonomous review is determined by policy.
  - id: cfd-0033
    title: Service recovery policy should grow circuit-breaker and backoff semantics before broader auto-resurrection
    category: architecture_debt
    severity: follow_up
    item_type: follow_up
    blocking: false
    status: open
    source_chunks:
      - chunk-000271-supervisor-auto-resurrection-policy-unplanned-failure
    source_sections:
      - Carry Forward
      - Other
    summary: >-
      Chunk 000271 intentionally implements a narrow one-shot local/dev
      resurrection proof. If Runtime auto-resurrection expands beyond this
      bounded proof, recovery policy should adopt explicit circuit-breaker
      style states and retry/backoff rules instead of repeatedly restarting
      services on every failed probe.
    evidence: >-
      A design check during chunk 000271 compared the current approach with
      common live-system recovery guidance: classify planned versus unplanned
      downtime, make recovery state explicit, avoid frontend truth inference,
      bound retries, use cooldown/backoff, and transition from planned
      maintenance to unavailable only after an expected-downtime boundary. The
      current chunk follows that model for one safe local/dev service with
      max_attempts=1 and cooldown metadata. Broader service recovery would need
      stronger states such as closed/open/half-open, jittered retry schedules,
      and probe-confirmed recovery before automatic resurrection becomes a
      general policy.
    reason_to_track: >-
      Without circuit-breaker/backoff semantics, expanded auto-resurrection can
      create restart loops, mask degraded dependencies, or produce noisy
      operator state transitions under persistent failure.
    owner_surface: Runtime supervisor recovery policy / service freshness controller / Runtime Action Panel service state
    revisit_trigger: >-
      Future service supervisor, auto-resurrection, service freshness,
      restart/recovery scheduler, or Action Panel service-state work expands
      recovery beyond the narrow local/dev one-shot proof.
    next_action: >-
      Before enabling broader automatic recovery, add a typed recovery state
      machine with explicit observed_failure, recovery_started,
      probe_half_open, recovered, recovery_failed, cooldown, and suppressed
      states; add bounded retry/backoff with jitter; expose expected downtime
      boundaries to the frontend when planned; and prove mocked frontend
      state-machine behavior before full-system restart/recovery browser proof.
  - id: cfd-0034
    title: Audit every Runtime and developer entrypoint for automatic work registration coverage
    category: runtime_debt
    severity: follow_up
    item_type: follow_up
    blocking: false
    status: open
    source_chunks:
      - chunk-000276-qa-executor-evidence-enforcement
      - chunk-000279-work-registration-entrypoint-coverage-validator-hardening
      - chunk-000280-pre-parallelism-readiness-summary
      - chunk-000281-architecture-drift-obsolete-path-detection-gate
      - chunk-000286-runtime-work-stack-parent-child-projection-foundation
      - chunk-000287-hosted-codex-activity-visibility-unregistered-work-diagnostic
      - chunk-000289-work-registration-entrypoint-coverage-validator-hardening
      - chunk-000293-role-work-visibility-e2e-proof-harness
      - chunk-000294-real-simulated-workflow-run
      - chunk-000295-live-work-session-task-process-visualization
      - chunk-000299-work-registration-advisory-entrypoint-adjudication
    source_sections:
      - Carry Forward
      - Validation
    summary: >-
      Runtime work visibility still depends on multiple entrypoint families
      and on a single-current-session projection that must represent nested or
      parallel work without hiding the parent role. Hosted Codex tool hooks,
      direct Runtime CLI branches, direct Node test files, legacy shell helpers,
      supervisor helpers, validation runners, browser smoke wrappers, and
      imported Runtime API functions now have a Runtime-owned advisory coverage
      report, but remaining ambiguous entrypoints and multi-active projection
      semantics need canonical tightening.
    evidence: >-
      During chunks 000275 and 000276, `sed`, `tail`, direct
      `node ai/runtime/test/runtime-test.mjs`, `node ai/runtime/dist/cli.js
      supervisor request`, `supervisor wait`, and Runtime socket CLI calls
      exposed inconsistent visibility. Hosted shell read commands are mapped
      through Codex hook policy, but hosted non-shell tools and direct Runtime
      entrypoints can bypass that layer. Runtime CLI socket work and
      supervisor request/wait paths now have direct automatic work contracts,
      and the Runtime test entrypoint starts a continuous Runtime Executor test
      contract after its work-session self-test phase. Chunk 000276 added
      `ai/runtime/src/modules/health/work-registration-entrypoint-coverage.ts`
      and the report
      `ai/reports/report-000276-work-registration-entrypoint-coverage.md`;
      the report covers CLI branches, Runtime API exports, Runtime socket
      method handlers, direct Node runtime tests, selected `ai/commands`
      facades, and shell-entrypoint registry classifications, with
      high-confidence missing direct Node test contracts fixed. A concrete
      runtime trace then showed the direct test contract registered and emitted
      journal events, but a short Codex filesystem-write child session marked
      the parent stale because the work-session model treated ad hoc child
      sessions as displacement rather than interruption. Chunk 000276 narrowed
      that by restoring active parent sessions after automatic or ad hoc child
      work completes. The remaining question is whether all ambiguous
      entrypoints and imported module calls have the same guarantee, and
      whether the Action Panel needs a true multi-active work projection rather
      than only a single current session plus interruption/restore.
      Chunk 000277 added an explicit Runtime Health
      `work_stack_projection` for the supported single-parent/foreground-child
      model and regression tests for automatic/ad hoc child completion, failed
      child restoration, stale-parent non-restoration, and unsupported parallel
      detection. This deliberately permits parallel tool/task execution only
      when represented as child/foreground work or detected as unsupported
      parallel evidence; it still does not claim multiple active roles are
      supported. Chunk 000279 hardened the Runtime-owned entrypoint coverage
      validator to emit current Markdown and YAML reports under `ai/reports`,
      expose classification/status/coverage counts, list high-confidence
      missing and advisory entries, and keep validation failing for
      high-confidence missing work-producing entrypoints. The generated report
      showed `missing_high_confidence_count: 0`; remaining gaps are advisory
      low-confidence classifications rather than known high-confidence bypasses.
      Chunk 000280 refreshed the same validator during pre-parallelism
      readiness and again reported 736 classified entrypoints, 0
      high-confidence missing gaps, and 62 advisory low-confidence entries.
      The readiness decision preserves the current supported model: one owning
      role with nested child/foreground work, while parallel tasks are allowed
      only when logged or detected explicitly and true parallel roles remain
      future work. Chunk 000281 added obsolete-state scanning to the Runtime
      architecture drift report; it found only advisory compatibility-state
      findings and no high-confidence local blocker. Chunk 000286 made the
      supported work-stack projection model explicit as
      `single_parent_foreground_child` in Runtime, backend GraphQL projection,
      frontend generated query types, and the Action Panel work-stack metadata.
      It does not add true parallel role support; task-level or multi-active
      role projection remains future scope under this CFD. Chunk 000287 added
      `hosted_codex_activity` to that projection so recent hosted Codex tool
      calls from the bounded Codex TUI log tail can be shown as
      `registration_gap_detected` when no fresh registered Runtime work is
      active. This is only a diagnostic: it is rendered as unregistered hosted
      activity, carries `accepted_as_work: false`, and keeps registered Runtime
      work authoritative when present. Chunk 000289 hardened the Runtime-owned
      entrypoint coverage validator by making high-confidence missing
      work-producing coverage and malformed explicit exemptions enforceable
      failures. Explicit exemptions now require an owner and reason, socket/YAML
      report generation preserves the full inventory, and synthetic Runtime
      tests prove both failure modes. The current report
      `ai/reports/report-000289-work-registration-entrypoint-inventory.yaml`
      shows 740 entrypoints, `missing_high_confidence_count: 0`,
      `exemption_issue_count: 0`, and 63 low-confidence advisory entries.
      Chunk 000293 extended the Runtime-owned Action Panel browser proof with
      `--work-visibility-foundation-proof`, selected `workStackProjection`
      through GraphQL, and proved parent/foreground-child visibility, parent
      restoration, and unregistered hosted Codex diagnostic rendering in the
      browser. This narrows the remaining gap to enforcement/coverage of
      work-producing entrypoints; it does not treat diagnostic hosted activity
      as accepted work and does not claim true parallel roles. During chunk
      000294, the operator observed that hosted file edits and backlog reorder
      actions could continue without fresh registered Runtime work; the ODE
      visualizer Developer session became stale before terminal completion, and
      the `000295` backlog insertion/reorder was not accepted registered work.
      Chunk 000295 is therefore scoped to project registered task/process cards
      under the owning Live Work Session role and to prove chunk/backlog actions
      appear either as registered Runtime lifecycle work or as unregistered
      hosted activity diagnostics, never silently disappearing. Chunk 000295
      then added Runtime/backend-owned normalized `live_work_display_items` with
      explicit display kinds/trust classes for accepted registered work,
      diagnostic-only unregistered hosted Codex activity, and unsupported
      concurrency. The Action Panel now renders those display items directly
      and no longer owns source-action category inference for the live-work
      cards. Browser proof showed registered work, diagnostic-only hosted
      activity, unsupported concurrency, and ad hoc recovery rendered in the
      live-work session while keeping registered Runtime work authoritative.
      Chunk 000299 adjudicated the remaining low-confidence entrypoint coverage
      advisories from the final reconciliation package. The generated report
      `ai/reports/report-000299-work-registration-entrypoint-coverage.yaml`
      now covers 747 entrypoints with `missing_high_confidence_count: 0`,
      `exemption_issue_count: 0`, and `advisory_count: 0`; reviewed legacy
      shell facades and Runtime API exports now carry explicit owner/reason
      exemptions, and direct Runtime CLI branches are classified by existing
      Runtime work wrappers, role preflights, or lifecycle authority.
    reason_to_track: >-
      The Runtime Action Panel cannot be authoritative if work disappears
      whenever a caller bypasses a shell hook or uses a direct Node/API
      entrypoint. Work-registration enforcement must be owned by Runtime
      entrypoints and core functions, not by operator memory or hosted hook
      behavior alone.
    owner_surface: Runtime CLI / Runtime API modules / Codex hook adapter / shell helpers / test runners / supervisor entrypoints / Action Panel work projection
    revisit_trigger: >-
      Future changes touch Runtime CLI commands, direct Node test files,
      `ai/commands/*` helpers, supervisor actions, validation/testing runners,
      lifecycle activation/closure, Codex hook configuration, or Runtime Health
      work-session projection.
    next_action: >-
      Keep the Runtime-owned entrypoint coverage validator current as new
      Runtime CLI/API/shell surfaces are added; the current 000299 report has
      no remaining advisory entries. Add representative regression tests for
      remaining hosted-tool visibility bypasses, including hosted tool names such as
      `exec_command`, `write_stdin`, `apply_patch`, `multi_tool_use.parallel`,
      shell read commands such as `rg`, `sed`, `tail`, `head`, `find`, and
      direct Runtime module invocations. Move high-confidence work-producing
      entrypoints toward hard enforcement: execute with an existing work
      contract, auto/ad-hoc register through Runtime-owned wrappers, or reject
      execution. Keep single owning role plus foreground child as the supported
      model, now explicitly reported as
      `single_parent_foreground_child`, until a future chunk adds a canonical
      task-level or multi-active role execution model. The display projection
      can now show unsupported concurrent sessions as a model warning, but a
      future execution model must still distinguish parallel tasks from
      parallel roles, log both without flattening, avoid stale parent rollback,
      and include the chunk/backlog action detection case added to chunk 000295.
  - id: cfd-0035
    title: Minimum downtime reload discipline across Runtime, backend, and frontend
    category: runtime_debt
    severity: follow_up
    item_type: follow_up
    blocking: false
    status: open
    source_chunks:
      - chunk-000295-live-work-session-task-process-visualization
    source_sections:
      - Carry Forward
      - Policy Enforcement
    summary: >-
      Runtime, backend, and frontend reloads should be scheduled at strategic
      safe points instead of triggered early during an edit sequence. The
      current freshness gate correctly blocks stale Runtime commands, but an
      eager build/reload can take the Action Panel or developer surface down
      while more edits are still in flight.
    evidence: >-
      During chunk 000295, Runtime source edits made the daemon stale and a
      `runtime_api_build_reload` supervisor request took about 109 seconds. The
      reload was safe and typed, but it happened before all planned edits were
      complete, creating avoidable downtime/reload churn. The same practical
      issue applies to frontend dev server, backend API, Runtime API, and typed
      supervisor reload paths.
    reason_to_track: >-
      Operators need the Action Panel and dev surfaces available for as much of
      the work chunk as possible. Minimum downtime should not slow the work
      materially, but disruptive reloads should be batched, ordered, and
      announced as planned maintenance only when a fresh daemon/server is
      needed for validation, browser proof, generated schema/codegen, or
      runtime-dependent commands.
    owner_surface: Runtime supervisor / frontend dev server / backend API / Runtime API freshness gate / validation runner
    revisit_trigger: >-
      Future work touches Runtime build/reload, backend or frontend dev-server
      restart behavior, freshness-gated tests, browser proof orchestration, or
      validation scheduling.
    next_action: >-
      Add a minimum-downtime reload planner that batches source edits, defers
      Runtime/backend/frontend reloads until the latest safe freshness-gated
      boundary, then executes the smallest typed reload sequence with visible
      planned-restart state and post-reload freshness proof. The planner should
      prefer build-before-stop and only stop/restart services when the built
      artifact is ready and a test/browser proof actually needs it.
  - id: cfd-0036
    title: Canonical command wrapper enforcement for hosted shell execution
    category: runtime_debt
    severity: follow_up
    item_type: follow_up
    blocking: false
    status: open
    source_chunks:
      - chunk-000295-live-work-session-task-process-visualization
    source_sections:
      - Carry Forward
      - Policy Enforcement
    summary: >-
      Work-producing repository commands should canonically run through
      `node ai/runtime/dist/cli.js command run -- ...` so Runtime work
      registration, foreground child projection, heartbeat, terminal status,
      and parent restoration do not depend on assistant memory or optional
      hosted Codex hooks.
    evidence: >-
      During chunk 000295, direct hosted `exec_command` calls and non-shell
      file-edit tools such as `apply_patch` could still occur without accepted
      Runtime work registration, and operator observation confirmed periods
      where work was happening while the Action Panel did not show it. A
      Runtime command wrapper was added and proved for already registered
      parent work and for the forgotten-registration case, where it creates ad
      hoc parent work automatically before running the foreground child
      command. A later apply_patch visibility gap was recovered with explicit
      ad hoc work and remains part of this guard scope.
    reason_to_track: >-
      Documentation alone is insufficient if hosted tools can bypass Runtime
      contracts. The remaining hardening should make wrapper use canonical in
      AI repository instructions and validators, detect direct work-producing
      commands that bypass the wrapper, and eventually reject or recover them
      with explicit ad hoc registration according to the work-registration
      policy. Non-shell tools that cannot be routed through the command wrapper
      need an equivalent pre-tool work-contract guard or mandatory ad hoc
      recovery before their edits are accepted.
    owner_surface: Runtime CLI / work-registration policy / shell-entrypoint registry / AI instructions
    revisit_trigger: >-
      Future work-producing shell commands, validation runners, testing
      wrappers, lifecycle tools, or hosted Codex hook/diagnostic changes are
      touched.
    next_action: >-
      Add guard validation that classifies repository command execution as
      accepted only when it is executed through the Runtime command wrapper, a
      typed Runtime entrypoint with an equivalent work contract, or a non-shell
      tool guard that starts/heartbeats Runtime work before mutation. Update AI
      instructions to make the wrapper the default command path for
      work-producing commands, keep pure inspection low-risk commands advisory
      until the guard is proven, and add browser proof that bypassed command or
      file-edit activity appears as diagnostic-only or is recovered through ad
      hoc work.
