# Runtime SOP This standard is the top-level operating procedure for AI runtime and orchestration work. Prompts should describe the delta intent; this SOP defines the default behavior unless a prompt explicitly overrides it. Specialized standards still own detailed mechanics: - machine-readable governance registries: `ai/governance/README.md` - approval validity and operator questions: `ai/standards/operator-questions.md` - close/commit and operator-visible docs/help governance: `ai/standards/runtime-tooling-governance.md` - Telegram notifications: `ai/standards/operator-notifications.md` - trusted daemon execution: `ai/standards/trusted-operator-daemon.md` - local/dev runtime model: `ai/standards/local-dev-runtime.md` - workflow handoff fields: `ai/standards/workflow-handoff.md` - carry-forward debt: `ai/standards/carry-forward-debt.md` - runtime event/actionability semantics: `ai/standards/runtime-event-semantics.md` - run-path graph, notification schedules, and local-agent permission policy: `ai/governance/registries/run-paths.yaml` - TypeScript runtime foundation: `ai/runtime/README.md` - Runtime State Engine and State Change Journal: `ai/standards/runtime-state-engine.md` ## Default Operating Rules - Authority principle: AI may propose. Runtime may enforce. Validators may verify. Only canonical transition engines may mutate authority state. - Stay inside the requested chunk or work item. - Stop after scoped work is complete; do not continue into unrelated runtime architecture, product work, or opportunistic cleanup. - Prefer DRY references to repeated policy text. - Prefer structured output over prose parsing for runtime automation. - Runtime functionality, daemons, service truth, validation/testing orchestration, notification truth, liveness truth, restart policy, and state transformation are Node/TypeScript-owned by default. Shell is limited to human convenience, bootstrap/startup, severe recovery, thin process facades, and basic local inspection. The canonical shell boundary lives in `ai/standards/shell-entrypoint-cutover.md`. - Use trusted-runtime status as authoritative and label sandbox-local probes as advisory. - Do not add arbitrary shell execution, hidden execution paths, tmux scraping, Codex wake/resume dependencies, or silent auto-continue behavior. - No silent failures: blocked, skipped, stale, or degraded states must be visible in the final summary, doctor/scorecard, or chunk notes. - Classify runtime/operator events before rendering them. Only actionable events may ask the operator for replies; Codex-internal, stale, validation, warning, or informational events must not request freeform input. - Select and validate the canonical run path before relying on phase-driven notifications or approvals. Required path semantics live in `ai/governance/registries/run-paths.yaml`; prompts may add delta intent but must not invent hidden paths. - Query Runtime concurrency policy before starting canonical runtime procedures. Lease, lock, singleton, replay, wait-graph, approval-consumption, validation-scheduling, build-coordination, lifecycle, and notification-order decisions live in `ai/governance/registries/runtime-concurrency.yaml` and Runtime API methods such as `runtime.canRun`, `runtime.lockGraph`, and `runtime.schedulerSnapshot`. ## Policy Enforcement Classes Every runtime/orchestration policy must be classified in the owning standard or chunk notes: - `Enforced`: backed by executable validation, schema, registry, state machine, hook, generated output, or test. - `Advisory`: guidance only. It may inform behavior but cannot be treated as a hard gate. - `Pending Enforcement`: required policy accepted, but enforcement is not implemented yet. It must be listed as a known risk and follow-up. Mandatory operating requirements must not remain prose-only. If a policy is mandatory but still prose-only, mark it `Pending Enforcement` and do not claim the behavior is deterministic. The target canonical registry owners live under `ai/governance/registries/`. Until the governance validator/generator migration is complete, existing enforced runtime surfaces remain authoritative compatibility projections. For example, Telegram command handling still uses `ai/tools/telegram/command-registry.tsv` as the enforced surface, while `ai/governance/registries/operator-commands.yaml` is the target canonical registry for upcoming validators and generators. Run governance checks with: ```sh node ai/runtime/dist/cli.js governance validate --json node ai/runtime/dist/cli.js governance validate --mode run-paths --json node ai/runtime/dist/cli.js validation-matrix --dry-run --json node ai/runtime/dist/cli.js validate --tier chunk --chunk ``` Validation tier policy: - Use `fast` during active implementation and after small registry/doc edits. - Use `chunk` before Ready-for-Human-Review transition for the current chunk. - Use `full` before close/commit recommendation or when Runtime Core, governance, scorecard, reconciliation, permissions, or shell-entrypoint policy changed. - Use `smoke` / `expensive-smoke` only when live transport, tmux/process, dispatcher, operator-daemon, or long historical reconciliation behavior is in scope. Normal fast/chunk/full validation must use Runtime CLI/API bounded snapshots. It must not scan full audit history, run live Telegram smoke, or invoke compatibility shell wrappers as canonical validation paths. Audit-state policy: - Hot/current runtime state is the only source for normal validation, scorecard, doctor, operator summaries, and reconciliation. - Historical audit files remain available, but only through explicit archive or historical Runtime API/CLI commands. - Operator-daemon request/result hot directories are bounded by the current index policy, default `100` records per source. - Archive maintenance uses `node ai/runtime/dist/cli.js audit archive-plan`, `audit archive-execute --dry-run`, `audit archive-execute`, `audit current-index`, and `audit historical-lookup`. - Fast/chunk/full tiers must not walk `.tmp/audit-archive/` or unbounded historical directories. Historical reconciliation and long audit review are smoke/explicit-only. - Action timeline/event-stream state follows the same policy. Normal runtime uses the bounded current timeline snapshot and current index. Historical event replay requires explicit `node ai/runtime/dist/cli.js timeline replay` or equivalent Runtime API calls. - Timeline hot state is bounded by `AI_RUNTIME_TIMELINE_KEEP_EVENTS`, default `250` events. Older events are archived under `.tmp/action-timeline/archive/YYYY-MM-DD.timeline.jsonl` and indexed under `.tmp/audit-index/action-timeline/`. Run-summary format is Runtime-owned. Prompts should not restate the canonical section list; use `node ai/runtime/dist/cli.js summary schema --json` for the schema, `summary validate --chunk --json` for enforcement, and `summary render --chunk --json` for the canonical model that backs Telegram compact summaries and `/details`. Canonical summary sections use exactly level-2 Markdown headings (`##
`); wrong heading levels are validation failures. Runtime summary validation rejects duplicate canonical summary sections, and Ready validation rejects duplicate canonical lifecycle evidence sections. Runtime execution defaults are Runtime-owned. Prompts describe work intent and only specify an override when intentional. Inspect defaults with: - `node ai/runtime/dist/cli.js runtime defaults --json` - `node ai/runtime/dist/cli.js runtime execution-policy --json` - `node ai/runtime/dist/cli.js runtime execution-modes --json` - `node ai/runtime/dist/cli.js runtime execution-mode --mode local_dev_fail_fast --json` - `node ai/runtime/dist/cli.js validation defaults --json` - `node ai/runtime/dist/cli.js testing defaults --json` - `node ai/runtime/dist/cli.js orchestration defaults --json` - `node ai/runtime/dist/cli.js summary schema-default --json` Prompts must not repeatedly redefine Runtime-owned summary sections, validation tiers, validation command lists, lifecycle sequencing, close gates, profile selection, or testing strategy. Execution attitude policy: - `assertive_solving` is the named policy for local/dev Runtime hardening, testing, proof-channel, service recovery, workflow observability, and scaffolding packages. See `ai/standards/assertive-solving.md`. - `local_dev_fail_fast` is the current local/dev default unless a prompt, registry, or authority boundary explicitly selects `conservative`. - `local_dev_fail_fast` uses `assertive_solving` behavior: repair safe local prerequisite gaps before advancing dependent chunks, retire replaced shell technology immediately when a Node/TypeScript/Runtime replacement is approved, and fail loudly with durable evidence instead of accumulating soft blockers. - `conservative` remains available for production-like, ambiguous, or authority-sensitive situations and stops for operator/consultant input before expanding scope to prerequisite implementation. - Neither mode may weaken lifecycle, approval, dispatcher, lease, close/commit, secret handling, test-database safety, Socket.IO invalidation-only behavior, or GraphQL/Runtime snapshot truth. Throughput policy: - Select a Runtime validation profile before ad hoc validation lists. Canonical profiles are inspected and run through `node ai/runtime/dist/cli.js validation profiles --json`, `node ai/runtime/dist/cli.js validation profile-defaults --json`, `node ai/runtime/dist/cli.js validation auto-profile --json`, `node ai/runtime/dist/cli.js validation execution-plan --profile --tier --changed-only --json`, `node ai/runtime/dist/cli.js validation profile --profile --json`, and `node ai/runtime/dist/cli.js validation run --profile --tier --changed-only --json`. Current profiles include `runtime-intrinsic`, `governance-policy`, `telegram-operator`, `frontend`, `backend`, `fullstack`, `docs-only`, and `smoke-release`. - Runtime validation should use the validation graph and cached Runtime API profiles before adding new expensive probes. - Use `node ai/runtime/dist/cli.js validation graph --json` to inspect dependencies and invalidation keys. - Use `node ai/runtime/dist/cli.js validation profile --tier --json` to measure validator timing and cache behavior. - Use `node ai/runtime/dist/cli.js validation plan --changed-only --json` before focused Runtime work to see the deterministic changed-only validator plan. - Use `node ai/runtime/dist/cli.js validation run --changed-only --json` for impacted-validator execution evidence, while preserving full validation as the close/commit gate. - Use `node ai/runtime/dist/cli.js runtime daemon-freshness --json` when timings look wrong or after Runtime source/build changes. Canonical Runtime CLI validation fails closed with `restart_required` if the daemon generation, source hash, or build hash is stale. - Guarded mutation owners must acquire and release Runtime leases through the Runtime API/CLI before executing. Lifecycle transitions, summary reconciliation, approval/question creation, dispatcher `close_commit`, timeline archives, and audit archives are lease-enforced. A rejected lease is the canonical conflict state; do not add shell-local locks or polling loops as alternate coordination. - Runtime builds use immutable generation directories plus build-state metadata. For AI/automation work, Runtime source changes must be applied through the registered supervisor action `runtime_api_build_reload`, which builds, reloads the Runtime API daemon, records service-status/journal evidence, and triggers the normal invalidation path. Direct `yarn --cwd ai/runtime build` is last-resort human/emergency compatibility only when the Runtime/supervisor path is unavailable or is itself the failed component; record that exception in chunk evidence. The underlying atomic build compiles into a staging generation, writes a runtime build manifest, moves the generation under `ai/runtime/.runtime-generations//`, and atomically points `ai/runtime/dist` at that immutable generation. During active build mutation, canonical Runtime CLI/API calls must fail closed or report `restart_required`; they must not silently trust partial or stale Runtime build state. Inspect this with `node ai/runtime/dist/cli.js runtime build-info --json`, `node ai/runtime/dist/cli.js runtime build-state --json`, `node ai/runtime/dist/cli.js runtime atomic-build-status --json`, `node ai/runtime/dist/cli.js runtime active-generation --json`, `node ai/runtime/dist/cli.js runtime generation-status --json`, and `node ai/runtime/dist/cli.js runtime atomic-activation-status --json`. - Use `node ai/runtime/dist/cli.js runtime snapshot-cached --json` and Runtime API batch requests for repeated status queries. - Cache invalidation must be fingerprint-based or explicit through `node ai/runtime/dist/cli.js validation invalidate --reason --json`. - Changed-path invalidation can use `node ai/runtime/dist/cli.js validation cache-invalidate --changed --json`. - Cache growth must remain bounded and visible through `node ai/runtime/dist/cli.js runtime cache-stats --json`. Doctor/scorecard exposes governance status, errors, warnings, and `Pending Enforcement` counts. Do not mark governance-sensitive work complete while those checks report errors. ## Authority And Lifecycle Ownership Lifecycle authority state is the durable repo/runtime state that controls whether work is draft, active, ready for human review, approved, completed, or committed. Prompt text, role-file prose, and final summaries may propose state changes, but they are not authoritative mutation engines. Canonical transition tooling owns lifecycle mutation: ```sh ai/chunks/validate-transition.sh --to "Ready for Human Review" ai/chunks/transition.sh --to "Ready for Human Review" ``` Read-only lifecycle/chunk validation logic is owned by Blueprint Runtime Core and surfaced through the shell entrypoints plus Runtime API inspection methods. The Runtime API may validate or summarize lifecycle state, but it must not mutate chunk status, complete chunks, stage files, or commit. Compatibility helpers and direct metadata edits are non-authoritative fallbacks unless they wrap the canonical transition tooling or are explicitly approved as manual recovery. Treat that gap as `Pending Enforcement` when it affects a chunk. Role ownership: - Developer implements scoped changes and records execution evidence. - QA independently reviews and records `PASS` or `BLOCKED` evidence. - Orchestrator coordinates lifecycle transition, approval boundaries, and next action. Ready-for-Human-Review evidence must keep those authorities separate: Developer evidence includes `Role: Developer`, QA review includes `Role: QA`, and Orchestrator handoff includes `Role: Orchestrator`. Developer may recommend review or next action, but does not own lifecycle transition, approval boundary, or close/commit authority. `Ready for Human Review` requires QA `PASS` evidence or an explicit human/operator QA override, plus Orchestrator coordination through transition tooling. Developer validation can prepare a chunk for QA, but Developer does not own the `Ready for Human Review` state. ## Bounded Autonomy SOP Bounded autonomy policy is owned by `ai/governance/registries/chunk-lifecycle.yaml` under `bounded_autonomy`. Governance validators enforce the first deterministic subset. Autonomous repair may continue only for deterministic, in-scope validation fixes when runtime state is authoritative/healthy and no approval boundary, destructive action, or new architecture decision is crossed. Autonomous repair must stop after two failed repair loops, runtime uncertainty/degradation, missing registered actions, policy conflicts, approval boundaries, product/security/auth/data decisions, or architecture choices. Agents must not use chat memory to decide whether a stop is optional. If the registry says stop, record the reason and stop. ## Run Path SOP Canonical run paths are finite and registry-backed. The current registry defines implementation, QA, validation repair, Ready transition, approval boundary, close/commit, blocked manual decision, stale artifact cleanup, and runtime note delivery paths. Each path owns: - phases. - legal phase transitions. - required evidence. - emitted event classes. - stop conditions. - approval boundaries. - allowed next paths. Notification scheduling is also registry-owned. Operators should receive messages because a phase emitted a canonical event that a schedule consumes, not because an AI session remembered to send one. Blueprint Runtime Executor is the live side-effect authority for migrated lifecycle, run-summary, operator-question, approval, and Telegram outbound-queue procedures. Codex/local-agent permission classes are registry-owned in `ai/governance/registries/runtime-permissions.yaml`, with a compatibility projection in `run-paths.yaml`. Repo inspection, status/diff/log, shell syntax checks, governance validators, lifecycle fixture tests, dry-run validation matrix, doctor JSON/KV, scorecard queries, Runtime API requests, shell wrapper tests, and scoped active-chunk repo edits are trusted local operations. Blueprint approval is still required for close/commit, lifecycle authority mutation, dispatcher authority execution, and registered daemon git actions. Operator approval remains required for pushes, package installs, external network access, database or secret mutation, destructive deletes, screenshot capture, and runtime-impact service restarts. Arbitrary shell execution APIs, hidden background execution, tmux scraping as an execution path, Codex wakeup execution dependency, and authority-state mutation without a registered action are forbidden. ## TypeScript Runtime SOP `ai/runtime/` is the target deterministic runtime core. Future migration should move pure logic into TypeScript first, keep registries canonical, and isolate side effects behind typed adapters. The Runtime API daemon is a local-only structured access layer for safe, repeatable runtime queries. It uses Unix socket JSON-line transport and exposes typed methods such as `runtime.health`, registry inspection, carry-forward listing, event rendering, run-path inspection, policy classification, operator-question summaries, approved-action classification, and read-only Telegram/notification render models, scorecard summaries, and doctor snapshots. It must not expose arbitrary shell execution, send live Telegram messages, execute recovery actions, or silently cross approval boundaries. Runtime API also exposes read-only dispatcher, operator-daemon, runtime-supervisor, integration-status, trusted-execution, and missing-action summaries. These projections are classified runtime visibility only: dispatcher execution, trusted daemon execution, supervisor restarts, and `close_commit` remain behind their existing guarded owners. Runtime API scheduling methods expose registry-backed run-path schedules, next phases, pending loops, phase summaries, and scheduler health. These methods are deterministic planning views only; they must not claim loops, execute phases, mutate authority state, or replace dispatcher/daemon/supervisor execution ownership. Runtime path harness methods are also read-only. They may run deterministic dry-run or fixture assertions against run paths, scheduler phases, validators, notifications, and authority boundaries, but they must not execute `close_commit`, mutate lifecycle state, dispatch approved actions, run daemon actions, or restart services. For migrated behavior, Runtime Core/API is preferred over shell internals. Shell entrypoints should remain as stable facades, bootstrap tools, process adapters, or guarded authority owners. New shell-only registry parsing, policy logic, or runtime procedure sequencing is forbidden; see `ai/standards/shell-entrypoint-cutover.md`. Shell compatibility policy: - Shell entrypoints remain the stable operator interface. - Safe read-only wrappers should route through Runtime API methods when the method is available. - Read-only wrappers may use an explicit legacy fallback if unavailable Runtime API access should not block the operator workflow. - Authority-state mutation wrappers must fail closed and remain with their guarded owners until migrated by a focused chunk. - Wrapper JSON output should reveal whether it used `runtime-api` or `legacy-fallback` where practical. Blueprint Runtime Executor now owns these live side-effect sequences: - lifecycle transition procedure through `runtime.executor.transition`. - Ready-for-Human-Review run summary plus close approval ordering. - operator question creation through `runtime.executor.createQuestion`. - close approval dedupe, supersession, and approved-action registration. - Telegram outbound message queue authorization through `runtime.executor.enqueueTelegram`. Runtime path execution classification is intentionally split: - Enforced: migrated Runtime Executor procedures listed above. - Advisory: deterministic run-path planning, harness simulation, and scorecard/doctor projection. - Pending Enforcement: full autonomous runtime execution, legacy Telegram prompt-handoff command projection, and remaining manual lifecycle recovery paths. The matching shell entrypoints are compatibility facades only: `ai/chunks/transition.sh`, `ai/tools/telegram/send-run-summary.mjs`, `ai/tools/telegram/send-message.mjs`, `ai/tools/operator-questions/ask.sh`, and `ai/tools/operator-notifications/post-run-recommendation.sh`. Current shell entrypoints remain authoritative only for side effects that are not migrated to Runtime Executor: - approved-action dispatcher execution. - operator-daemon registered actions. - approval/approved-action cleanup operations until explicitly migrated. Runtime Core may classify pending, approved, denied, consumed, stale, ignored, superseded, invalid, and resolved-stale approval state. Dispatcher and trusted daemon ownership still define execution authority. - runtime-supervisor restarts. - Telegram transport: the bridge may poll Telegram, send already authorized outbound queue messages, record inbound reply decisions, render details for Runtime Executor-created questions, and maintain heartbeat/status. It must not create approvals, create questions, create summaries, sequence lifecycle phases, or execute close_commit. - runtime scorecard trusted probes. Do not replace those side effects opportunistically. Migrate one ownership area at a time, with tests and validators, while leaving shell wrappers as compatibility entrypoints where practical. ## Chunk Creation SOP Continue the latest relevant active chunk by default. Do not create a new chunk unless one of these is true: - the operator explicitly asks for a new chunk. - existing active chunks are clearly unrelated. - lifecycle policy requires a separate chunk and the final summary explains why. - chunk creation is done through a canonical chunk creation command or policy gate. Any run that creates a new chunk must state why in `Details` and in the chunk handoff. Doctor/scorecard should warn when multiple active chunks exist so QA can check for unintentional chunk proliferation. ## Role Reference SOP When a prompt or standard names an AI role such as Orchestrator, Developer, QA, Requirements, or Chunk Planner, resolve that role to the durable role file under `ai/roles/*.md`. Typos in a prompt, for example `orchstrator`, do not create a new role or policy source. Role files may reference canonical standards and registries, but required runtime behavior must still be enforced by validators, generated surfaces, state-machine tooling, or tests. ## Ready For Human Review `Ready for Human Review` means: - scoped work is complete. - acceptance criteria are updated. - QA has returned `PASS`, or an explicit human/operator QA override is recorded in the chunk. - validation was run or explicitly skipped with rationale. - runtime state is clean enough to hand off. - no known blocker remains inside the requested scope. - any required restart was performed and verified, or a concrete blocker is recorded. - mandatory validations are not pending, misleading, failed, or contradicted by runtime status. It does not mean the chunk may be archived or committed without the required approval path. Use the lifecycle transition tooling for status changes when practical: ```sh ai/chunks/validate-transition.sh --to "Ready for Human Review" ai/chunks/transition.sh --to "Ready for Human Review" ``` Manual status edits are a compatibility fallback only. The transition helper records transition evidence and exposes whether a close/commit approval side-effect is required, created, suppressed, or still pending enforcement. ## Automatic Close/Commit Approval If a chunk or work item is `Ready for Human Review`, the runtime recommendation is close/commit, and the operator did not explicitly request hold/no-commit, then a fresh `close_commit` approval must be created automatically. This must not depend on prompt wording or model memory. Exceptions: - the operator explicitly requested hold/no-commit. - degraded runtime prevents safe approval creation. - the pass is intentionally review-only or doc-only and explicitly marked `no-close-requested`. The final summary must state: - whether approval was created. - why approval was or was not created. - the approval question id when applicable. - the hold reason when no approval was created because of a blocker. Approval authorizes deterministic dispatcher execution, not direct Codex continuation. Detailed close/commit approval semantics are in `ai/standards/runtime-tooling-governance.md`. ## Validation SOP Required validation is defined by the chunk and by impacted standards. In general: - standards-only or doc-only changes may skip unrelated implementation tests. - implementation changes must run impacted tests and runtime checks. - runtime/tooling changes must validate the affected helper paths and machine-readable status where practical. - skipped validations must be listed explicitly in the final summary with a concrete reason. - environment-limited validation must include the exact blocker and residual risk. Do not claim PASS from clean prose alone when machine, fixture, runtime, or scenario validation applies. ## Cleanup SOP At end of run: - no orphaned background validation process may remain. - long-running services are acceptable only when they are canonical trusted runtime services documented in `ai/standards/local-dev-runtime.md`. - temporary validation terminals, fixture sessions, and test artifacts must complete, be cleaned up, or be explicitly documented. - `.tmp`, runtime state, logs, screenshots, secrets, local DB files, and build output must not be staged. - runtime state should end clean unless a specific degraded or stale state is documented with a recovery action. ## Final Summary SOP Local final summaries, assistant final chat responses that close or pause an orchestration/chunk run, and Telegram `/details` for orchestration/runtime work must use these sections in this order: 1. `Details` 2. `Good` 3. `Bad` 4. `Ugly` 5. `Validation` 6. `Next` `Details` comes first and should be useful when pasted into a future AI session. Include the relevant chunk ids/statuses, runtime health, changed areas, pending questions/actions, missing actions, warnings, important decisions, approval state, and remaining fragility. `Good`, `Bad`, and `Ugly` are human-readable interpretation, not a duplicate raw state dump. Use `None` when a category has no meaningful item. `Validation` lists commands and results, including skipped commands with rationale. `Next` names the next command, approval, or operator action. Unresolved significant `Bad` or `Ugly` items must either be resolved, explicitly accepted as not applicable, or recorded in the carry-forward debt registry defined by `ai/standards/carry-forward-debt.md`. The summary must distinguish blocking carry-forward debt from non-blocking warnings, advisories, compatibility debt, observations, follow-ups, and pending enforcement. Do not let runtime anomalies, governance debt, validation debt, operator UX debt, or reconciliation issues disappear between chunks. Machine-readable summaries, YAML packets, export bundles, dashboards, and detail-mode reports should use Runtime scorecard/health carry-forward projections or the canonical registry. They should include counts/classes where practical and must not infer carry-forward status from narrative text alone. Compact Telegram summaries should use the same truth but remain mobile-first: short `Good`, `Bad`, `Ugly`, `Next`, plus `More: /details`. Do not dump raw JSON or verbose console output into Telegram by default. Do not rely on short-term chat memory for this shape. When a run is closing, pausing at an approval boundary, or reporting a stop condition, render or mirror the canonical Runtime summary model where available. If the response is a tiny status-only answer or a non-workflow question, this section shape is optional; for chunk/package completion, close/commit, stop-condition, or operator-review handoff responses it is required. Repository tooling validates chunk artifacts and Telegram/detail output, but assistant chat output is a policy-bound surface; until platform-level enforcement exists, QA must review representative final chat output against this SOP for workflow/runtime chunks. ## Runtime Surface Separation Console/runtime shell is the primary operational/debug surface: - verbose diagnostics. - raw doctor/scorecard output. - timeline filtering and archive inspection. - detailed logs and structured JSON/KV. Telegram/mobile is the compact operator surface: - approvals and concise awareness. - short summaries. - scoped `/details`. - compact `/timeline`. - next action or recovery command. Telegram should reference canonical console commands for deep inspection rather than duplicating full console output. ## Reconciliation SOP Runtime Core reconciliation is the canonical read-only interpretation layer for stale approvals, dispatcher results, retry-succeeded actions, duplicate runtime events, and transient probe failures. Operator surfaces, scorecard, and doctor should consume the reconciled classification instead of independently deciding whether stale or failed-then-succeeded artifacts are actionable. Reconciliation visibility does not authorize execution. `retry_succeeded` artifacts are non-actionable success for operator flow, but remain visible as audit evidence and carry-forward context until the underlying idempotency or cleanup issue is actually fixed. See `ai/standards/runtime-reconciliation.md`. ## Timeline SOP The canonical action timeline should be inspected with: ```sh ai/tools/action-timeline/list.sh --human ai/tools/action-timeline/list.sh --telegram ai/tools/action-timeline/list.sh --json ai/tools/action-timeline/list.sh --human --filter ai/tools/action-timeline/archive.sh --dry-run ``` Default timeline views should suppress noisy repeated stale/history events and emphasize current actionable state, recent important failures/successes, and suggested next action. Use `--all` only for debugging. ## QA Enforcement QA should block when: - required final summary sections are missing or out of order. - approval state is omitted when close/commit is relevant. - automatic close/commit approval is missing when this SOP requires it. - skipped validations are silent or unjustified. - operator-visible behavior changed without docs/help/status/Telegram updates. - runtime/operator-surface behavior changes without passing the canonical operator-surface validation: ```sh node ai/runtime/dist/cli.js telegram operator-surface --json ``` - a runtime component needs restart but the final summary omits whether restart was required, performed, and verified. - runtime/tooling changes duplicate policy instead of referencing canonical standards. - new chunks are created without an explicit operator request, unrelated-active chunk rationale, lifecycle policy reason, or canonical chunk creation gate. - hidden execution paths, arbitrary shell execution, tmux scraping, or Codex wake/resume are used as approved-action execution paths. - cleanup leaves orphaned non-canonical processes or staged runtime artifacts.