# Design Documents

Catalog of architectural decisions and design rationale for the MARS project.

| Document | Status | Summary |
|----------|--------|---------|
| [tenets.md](tenets.md) | Accepted | The 9 founding tenets: plug and play, self-improving system, accuracy scoring, customisable guardrails, roadmap from init, blast radius containment, execution truth, progressive autonomy, context efficiency |
| [implementation-language.md](implementation-language.md) | Accepted | Why Go is the foundation implementation language: single binary, low runtime dependency burden, local orchestration fit, and subprocess boundaries for inference. AD-001. |
| [agent-runtime.md](agent-runtime.md) | Draft | Agent execution loop: multi-turn conversation, tool calling, error handling, budget enforcement. AD-004 (sync per-job), AD-005 (sequential tools), AD-006 (additive context) |
| [local-inference.md](local-inference.md) | Draft | Local model serving: llama.cpp as subprocess, hardware profiles, model registry, download management. AD-007 (no CGO), AD-008 (weights in ~/.mars/), AD-031 (inference resilience), AD-032 (zero-config performance tuning), AD-063 (benchmark-backed model promotion), AD-064 (manifest-tier routing), AD-066 (Ollama catalog/swap provider), AD-299 (start endpoint override, safe scoped cleanup, and port reservations) |
| [scoring-system.md](scoring-system.md) | Draft | Accuracy and value scoring: outcome tracking, rolling scores, progressive autonomy thresholds, noop detection |
| [self-improvement.md](self-improvement.md) | Draft | Intervention detection, Reviewer meta-role, bounded evolution commits, before/after tracking, safety rails. AD-071 (active plan drift), AD-073 (single active exec plan with dependencies), AD-276 (pipeline-learnings tracker retired), AD-277 (completed snapshot docs retired) |
| [guardrails.md](guardrails.md) | Draft | Advisory vs hard guardrails, validation types, override mechanism, staleness detection, workspace hygiene, bounded ticket lifecycle move exceptions, and bounded repo/module-local build artifact cleanup. AD-012, AD-107, AD-115, AD-142. |
| [pipeline-engine.md](pipeline-engine.md) | Draft | Job queue (SQLite), worker dispatcher, cron scheduler, sandbox, and startup-safe SQLite WAL recovery. AD-009 (SQLite), AD-010 (repo_id from day one), AD-214 (preserve WAL state) |
| [dashboard.md](dashboard.md) | Draft | Legacy/current embedded dashboard plus planned TanStack Start control plane. AD-011 (htmx + Chart.js embedded), AD-156 (TanStack sidecar behind Go gateway), AD-279 (single-binary constraint scope), AD-310 (fail-closed embedded browser gateway). |
| [github-app-integration.md](github-app-integration.md) | Accepted | Loopback listener boundary plus authenticated, numerically authorized, repository/branch/fork-aware, replay-safe GitHub webhook ingress. AD-309. |
| [context-efficiency.md](context-efficiency.md) | Draft | Context assembly, budgets, run metadata, knowledge routing, guardrail scoping. AD-208, AD-288 (served-window clamp + calibrated estimation). |
| [harness-operating-model.md](harness-operating-model.md) | Accepted | Canonical six-domain operating model with explicit role mode metadata, checked role registry, persona manuals, and structured dispatch handoffs. AD-084, AD-085, AD-105, AD-106. |
| [conversation-as-system-record.md](conversation-as-system-record.md) | Accepted | Significant conversations must become durable repo artifacts for plans, decisions, investigations, quality evidence, and completed work. AD-086. |
| [harness-glossary.md](harness-glossary.md) | Accepted | First-class and contextual harness definitions mirrored between the foundation harness and deployed harnesses. |
| [foundation-deployed-harness-architecture.md](foundation-deployed-harness-architecture.md) | Accepted | Foundation harness, runtime substrate, deployed harness, target project, mirrored operating-model core, feedback routing, failure ownership classification, tool/skill/binary boundaries, and doctrine maintenance. AD-139. |
| [tools-glossary.md](tools-glossary.md) | Accepted | First-class mirrored tool availability, selection, and use-case context for foundation and deployed harnesses. |
| [code-documentation-map.md](code-documentation-map.md) | Accepted | Source-prefix to documentation ownership map checked by `docsync audit`. AD-101. |
| [documentation-sync-architecture.md](documentation-sync-architecture.md) | Accepted | Architecture and universal operating model for `MarsDocSync`, docsync audit, generated target mirroring, and stale-doc prevention. AD-102. |
| [cli-tool-skill-sync.md](cli-tool-skill-sync.md) | Accepted | Foundational operating model for keeping `mars_cli`, repo shortcuts, generated target doctrine, and skills synchronized with CLI changes. AD-103. |
| [trigger-orchestration.md](trigger-orchestration.md) | Draft | Trigger sources (webhook, schedule, chain), upstream chaining via `then`, custom cron, strict-trunk default roles, and native Orchestrator surveys. AD-016 through AD-020, AD-089. |
| [orchestrated-organization-layer.md](orchestrated-organization-layer.md) | Accepted | Default dispatch-mode organization/liveness layer around the queue and manifest roles, with deterministic disposition routing, Orchestrator fallback, failed-Orchestrator recursion containment, protocol-failure containment, stale ticket-owner survey cleanup, forward-only completed review handoffs, and Dogfood-before-governance product validation. AD-090, AD-114, AD-118 through AD-120, AD-128. |
| [dogfood-and-decisions.md](dogfood-and-decisions.md) | Accepted | Containerised E2E validation (Podman + native fallback), decision recording tool, strict-trunk pipeline for local use, ticket-drain discipline, recovery loop containment, queue self-healing, tool-creation scaffolding, mirrored CLI interaction, MCP tool exposure, bootstrap trust defaults, destructive shell gates, intervention-debt signal dedupe, file-count blast-radius calibration, and product-first lifecycle stabilization. AD-021 through AD-030, AD-033, AD-060, AD-062, AD-077, AD-079, AD-087, AD-091 through AD-094, AD-109. |
| [dogfood-matrix.md](dogfood-matrix.md) | Accepted | Source dogfood matrix and Mars observer-mode supersession benchmark. AD-088. |
| [mirrored-harness-and-context-glossary.md](mirrored-harness-and-context-glossary.md) | Accepted | Source and initialized harness parity, glossary-as-route context, repo-owned workflow contracts, operating-rule inheritance, and rationale-bearing architecture/product docs. AD-034 through AD-036, AD-058, AD-061. |
| [self-reflective-telemetry.md](self-reflective-telemetry.md) | Accepted | Harness grades itself and triages telemetry into prompt, skill, process, guardrail, context, inference, manifest, and tool-policy improvement targets, with opt-in aggregate foundation telemetry whose transport is not anonymous. AD-037 through AD-039, AD-065, AD-072, AD-104, AD-277 (quality-score regeneration cadence). |
| [product-spec-governance.md](product-spec-governance.md) | Accepted | Product specs as a living product contract with metadata, index coverage, and docs-consistency enforcement. AD-040 through AD-042. |
| [generated-docs-governance.md](generated-docs-governance.md) | Accepted | Generated docs as reproducible reference snapshots with catalog and docs-consistency checks. AD-043 through AD-045. |
| [role-customization.md](role-customization.md) | Accepted | Shipped roles as configurable starter agents; target manifests, prompts, knowledge routes, and guardrails are user-owned after init. AD-046 through AD-048. |
| [release-versioning.md](release-versioning.md) | Accepted | Semantic versioning, detailed generated patch notes, historical release-note backfills, repository-owned release producers, self-update, release assets, shell PATH setup, and retained historical publication decisions. AD-049 through AD-051, AD-056 through AD-057, AD-059, AD-068 through AD-070, AD-075, AD-078, AD-099 through AD-100, AD-141, AD-312 through AD-313, AD-315. |
| [skill-evolution.md](skill-evolution.md) | Accepted | Skills as a first-class self-improvement target, the decision matrix for prompt, skill, tool, guardrail, or knowledge-route changes, and the boundary between recursive improvement doctrine and release-publication skills. AD-052 through AD-055, AD-140. |
| [source-quality-gates.md](source-quality-gates.md) | Accepted | Local mechanical quality gates for the source repo: per-package coverage ratchet floors, fuzzed hostile-model-output parsers, fail-closed govulncheck enforcement, and the exact Go 1.25.13 source compatibility floor without an external Go requirement for packaged operation. AD-280, AD-281, AD-314. |
| [validation-matrix-gating.md](validation-matrix-gating.md) | Accepted | Source-only doctrine mapping source-change classes to minimum AD-138 archetype replays, plus the fixed validation evidence recording contract. AD-284, AD-285. |
| [foundation-operating-model.md](foundation-operating-model.md) | Accepted | Source-only canonical foundation operating model: every foundation runtime change validates via clean-project harness replay (AD-291), foundation improvement loop (AD-292), compartmentalised agent smoke (AD-294), confidence-gated planning for foundation observations (AD-298), primary outcome contract gating for support-only claims (AD-300), external AI-client role-subagent operation (AD-304), foundation Orchestrator planning model consumption by external tools (AD-308), anti-patterns, and links to AD-138/AD-284. |
| [agent-smoke-validation.md](agent-smoke-validation.md) | Accepted | Compartmentalised agent-smoke design: live selected-role execution through the server job path, parallel ephemeral target isolation, source-only foundation-maintainer handling, and fake endpoint exclusion. AD-295, AD-296. |
| [ephemeral-validation-runtimes.md](ephemeral-validation-runtimes.md) | Accepted | Optional external runtimes such as Node-based visual testing tools are allowed for job-scoped validation only when setup, artifacts, processes, cleanup, and failure ownership are bounded. AD-293. |
| [convergence-state-machine.md](convergence-state-machine.md) | Accepted | The delivery lifecycle as an explicit state machine: named states/transitions, every convergence guardrail as an edge guard, the block-message contract, the complete AD-164..AD-275 mapping, the interpretation layer, the three missing-transition classes, and the T-029 session-state implementation sketch. AD-286. |
| [policy-decomposition.md](policy-decomposition.md) | Accepted | Ordered same-package decomposition of internal/tools/policy.go (7,091 lines / 354 functions) into domain files with lockstep test splits, per-file MarsDocSync, browser-first extraction sequence, checkpoint replay gates, and the two-change-class boundary against AD-286 state-machine slices. AD-287. |
| [cognition-orchestration-patterns.md](cognition-orchestration-patterns.md) | Draft | Audit-grade mapping of AWS agentic AI patterns to MARS local cognition-orchestration architecture, including workflow typing, route rationale, scatter-gather aggregation, simulation episodes, evidence-bound evaluator loops, and saga compensation. AD-307. |
| [board-driven-integrations.md](board-driven-integrations.md) | Draft | Optional board-driven integrations profile for JIRA intake, Figma context, human-reviewed delivery, and future gateway model routing, defaulting safely to the existing CEO-led strict-trunk flow. AD-302. |
| [delivery-operating-model.md](delivery-operating-model.md) | Accepted | BDD-led goal-driven walking-skeleton delivery as the source and generated target operating model, including remote trunk freshness, immediate publishing, source live-experience verification, non-recursive dispatch recovery, ticket-backed Engineer dispatch, bounded ticket-gate repair, protocol-failure containment, stale ticket-owner survey cleanup, forward-only completed review handoffs, runtime-learning metadata handoff tolerance and auto-commit, COO planning-only implementation boundaries, QA-before-more-planning after completed Engineer work, terminal-tool recovery, QA repo inspection, inline tool-call compatibility, Dogfood-before-governance product validation, deterministic direct product handoffs, CEO goal boundaries, QA approval validation-loop containment, tool-first QA review on a tool-reliable model tier, preflight enforcement of done-ticket evidence, runtime-failure dispatch stops, atomic ticket lifecycle moves, duplicate scenario/title cleanup, observation-first Dogfood validation, claim-backed Engineer product mutation, live demo improvement loops, canonical bootstrap feature-contract reuse, early product-ticket batches, one-ticket Engineer handoff boundaries, browser validation-helper lanes, planner shell-mutation containment, product capability extraction boundaries, failure ownership classification, and dispatch-named rework routing. AD-074, AD-081, AD-108, AD-110, AD-114, AD-116 through AD-138, AD-143, AD-240 through AD-253. |

## Architecture Decision Log

| ID | Decision | Design Doc | Milestone |
|---|---|---|---|
| AD-001 | Go as implementation language. Single binary, no CGO, local orchestration fit, and inference kept behind subprocess/provider boundaries. | implementation-language.md | M0 |
| AD-002 | Apache 2.0 license | index.md | M0 |
| AD-003 | Repo governance follows Mars conventions (AGENTS.md, design docs, exec plans, commit discipline) | AGENTS.md | M0 |
| AD-004 | Synchronous single-threaded agent loop per job. Concurrency at job level. | agent-runtime.md | M1 |
| AD-005 | Sequential tool execution, not parallel. Simpler, safer, easier to trace. | agent-runtime.md | M1 |
| AD-006 | Additive context assembly (concatenation with section headers). No template engines. | agent-runtime.md | M1 |
| AD-007 | llama.cpp managed as subprocess, not embedded via CGO. Clean binary distribution. | local-inference.md | M2 |
| AD-008 | Model weights stored in ~/.mars/models/, not in repo. SHA256 in bundle.lock.json. | local-inference.md | M2 |
| AD-009 | SQLite for all persistent state (jobs, scores, interventions, traces). Zero external dependency. | pipeline-engine.md | M5 |
| AD-010 | repo_id column in schema from day one. Multi-repo ready even if v1 is single-repo. | pipeline-engine.md | M5 |
| AD-011 | htmx + Chart.js embedded in Go binary for dashboard. No React, no npm, no external dependencies. | dashboard.md | M9 |
| AD-012 | Hard guardrails limited to syntactic checks in v1 (regex, file pattern, file existence). AST analysis is v2. | guardrails.md | M7 |
| AD-013 | `log/slog` from stdlib for all structured logging. JSON in production, text in development. | AGENTS.md | M0 |
| AD-014 | Domain-grouped packages under `internal/` (agent, llm, tools, github, etc.). Public types in `pkg/` if needed. | AGENTS.md | M0 |
| AD-015 | YAML config file (`~/.mars/config.yaml`) merged with environment variable overrides (`MARS_` prefix). | AGENTS.md | M0 |
| AD-016 | Three trigger source types: webhook, schedule, chain. No expression parser in v1. | trigger-orchestration.md | Orchestrator |
| AD-017 | Upstream chaining via `then` field. Direct chains vs event-mediated chains. | trigger-orchestration.md | Orchestrator |
| AD-018 | Fire-and-forget `OnComplete` hook, not a full event bus. Extension point for v2. | trigger-orchestration.md | Orchestrator |
| AD-019 | Custom cron with named presets (`hourly`, `daily`, `weekly`, `monthly`) as aliases. Standard 5-field only. | trigger-orchestration.md | Orchestrator |
| AD-020 | Strict trunk keeps default roles schedule- and chain-driven; compatibility event handlers must be explicit. | trigger-orchestration.md | Orchestrator |
| AD-021 | Dogfood tester uses Podman containers with graceful native fallback. Auto-generated Containerfile from conventions. | dogfood-and-decisions.md | Dogfood |
| AD-022 | `record_decision` is a first-class agent tool, not a file-write convention. Decisions persist in `.harness/learnings.yaml` and are injected into all future agent context. | dogfood-and-decisions.md | Dogfood |
| AD-023 | Agents push after every semantic commit. Work must never be trapped locally. | dogfood-and-decisions.md | Dogfood |
| AD-024 | Strict-trunk default pipeline for local use. Optional webhook integrations add telemetry and repair triggers without replacing direct commits to `main`. | dogfood-and-decisions.md | Dogfood |
| AD-025 | Dogfood chains from Engineer (not schedule-only) so builds are validated after every feature when harness isn't always-on. | dogfood-and-decisions.md | Dogfood |
| AD-026 | Bootability checks: scanner detects unbootable projects (missing scripts, root layout, Tailwind config, conflicting dirs); Engineer must build-verify before closing tickets; Dogfood runs pre-flight structural checks; QA validates structural integrity. | dogfood-and-decisions.md | Bootability |
| AD-027 | Interactive control surface: CLI key listener (p/r/s/q/h) + dashboard control bar. Shared Server methods, warm restart, pause/resume workers, scan repos, run specific roles. | dashboard.md | Controls |
| AD-028 | Git tools (`git_status`, `git_diff`, `git_commit`, `git_push`) added to all write-capable role manifests. Commit gates in prompts enforce clean working tree before run ends. Scanner detects missing `.gitignore`. | dogfood-and-decisions.md | Git discipline |
| AD-029 | Per-repo database isolation. Default DB path changed from `~/.mars-harness/db/mars.db` to `~/.mars/db/{repo-slug}/mars.db`. `RepoScope` filter in `serve.Config` as defense-in-depth. `doctorCmd` gains `--repo` flag. Migration warning for legacy DB. | dogfood-and-decisions.md | Isolation |
| AD-030 | Mechanical ticket deduplication. `ticket_create` tool with built-in duplicate detection (normalized title subset matching). Ticket index injected into context assembly for COO/engineer/janitor. COO prompt rewritten to use tool-level enforcement. Scaffold template cleaned of Mars-specific boilerplate. | dogfood-and-decisions.md | Ticket dedup |
| AD-031 | Inference resilience. HTTP timeout 60s→5min for local inference. Fast-tier context 8192→16384 (Gemma 4 supports 128k). Active health spot-check in router before returning endpoint (catches stale healthy state from crashed servers). Non-retryable error for context-exceeded. Retry backoff increased across client and agent loop. | local-inference.md | Resilience |
| AD-032 | Zero-config local inference performance profile and llama tuning. Auto profile selects smaller Q4/Q5 defaults on memory-constrained unified-memory machines while keeping overrides available. Default parallel slots are capped at 1 for strict-trunk single-agent throughput. | local-inference.md | Performance |
| AD-033 | Eligible in-progress tickets are drained before backlog work. Engineer gates accept done, blocker, dependency, or guardrail-blocked intervention-debt outcomes, while tool policy blocks ordinary backlog creation during active drain and scanner/doctor route stale ticket state to Janitor. | dogfood-and-decisions.md | Ticket completion |
| AD-034 | Source and initialized harnesses must mirror operating doctrine: compact AGENTS.md, strict trunk, ticket workflow, design decisions, references, and knowledge routing. | mirrored-harness-and-context-glossary.md | Generated targets |
| AD-035 | Context glossary is a routing layer, not a prompt-stuffed manual. Initialized repos get `docs/design-docs/context-glossary.md` and `.harness/knowledge/context-glossary.yaml`. | mirrored-harness-and-context-glossary.md | Context |
| AD-036 | Workflow contracts belong in repo-owned artifacts. Current v1 contract is AGENTS.md + manifest + ticket docs + exec-plan docs + knowledge routes; a first-class WORKFLOW.md remains a future option. | mirrored-harness-and-context-glossary.md | Orchestration |
| AD-037 | Telemetry must be triaged into explicit improvement targets: prompt, skill, process, guardrail, context, inference, manifest, tool policy, or unknown. | self-reflective-telemetry.md | Self-improvement |
| AD-038 | Scores are control signals, not vanity metrics. Low rolling scores with enough samples trigger triage and bounded evolution review. | self-reflective-telemetry.md | Scoring |
| AD-039 | Self-improvement is proactive but bounded. Direct edits stay inside allowlisted harness surfaces; process/product changes become tickets or plans unless trust and scope allow direct evolution. | self-reflective-telemetry.md | Safety |
| AD-040 | Product specs are a living product contract, updated with product-facing changes and carrying status, update date, and owner metadata. | product-spec-governance.md | Docs |
| AD-041 | Product specs link to design docs, exec plans, references, and tickets instead of duplicating all supporting context. | product-spec-governance.md | Context |
| AD-042 | Product spec freshness is mechanically checked through docs-consistency tests for metadata, index coverage, links, and strict trunk wording. | product-spec-governance.md | Quality |
| AD-043 | Generated docs are reproducible reference snapshots, not hand-written decisions, tickets, product specs, or plans. | generated-docs-governance.md | Docs |
| AD-044 | Empty generated docs are acceptable until a generator exists, as long as the README states that intentionally. | generated-docs-governance.md | Docs |
| AD-045 | Generated docs must be cataloged and mechanically checked for README metadata, catalog coverage, and valid links. | generated-docs-governance.md | Quality |
| AD-046 | Shipped roles are starter agents, not a claim of universal correctness. Users may edit, replace, remove, or add roles. | role-customization.md | Roles |
| AD-047 | Target role configuration is user-owned once generated: manifest, prompts, knowledge routes, and guardrails are preserved by default. | role-customization.md | Upgrade |
| AD-048 | Upgrade fills missing defaults and does not silently retune existing agents. New prompt wording must be adopted deliberately. | role-customization.md | Upgrade |
| AD-049 | VERSION is the semantic version source for MARS and initialized target repos. | release-versioning.md | Release |
| AD-050 | CHANGELOG.md stores generated patch notes with release markers so future runs can find new commits. | release-versioning.md | Release |
| AD-051 | Source and target release behavior mirrors through generated VERSION, CHANGELOG.md, release guidance, knowledge routes, and release-manager prompts. | release-versioning.md | Generated targets |
| AD-052 | Skills are a first-class evolution target when repeated failures or interventions reveal missing reusable procedure. | skill-evolution.md | Self-improvement |
| AD-053 | Skills must stay compact, scoped, evidence-oriented, and separate from large manuals or role identity. | skill-evolution.md | Context |
| AD-054 | Evolution triage chooses between prompt, skill, tool, guardrail, knowledge route, inference/config, manifest/tool policy, or tickets by evidence type. | skill-evolution.md | Self-improvement |
| AD-055 | Initialized target harnesses receive skill-evolution guidance so source and target workflows reduce human intervention the same way. | skill-evolution.md | Generated targets |
| AD-056 | Every non-release semantic commit to this source repo is followed by generated release notes and a `release: notes X.Y.Z` commit before the task is done. | release-versioning.md | Release |
| AD-057 | Initialized target repos inherit the same automatic versioning workflow through generated AGENTS.md, release-versioning docs, and release-manager prompts. | release-versioning.md | Generated targets |
| AD-058 | Operating rules added to the source harness apply to initialized target harnesses unless explicitly marked source-only. | mirrored-harness-and-context-glossary.md | Generated targets |
| AD-059 | Superseded by AD-313/T-065: versioned source releases used the retired bespoke local-asset publisher and optional GitHub mirror. | release-versioning.md | Release |
| AD-060 | Failed auto-recovery jobs do not recursively enqueue more recovery jobs, and active recovery is idempotent by repo and role. | dogfood-and-decisions.md | Recovery |
| AD-061 | Architecture changes and product features must be documented with their rationale, and the rule mirrors into initialized target harnesses. | mirrored-harness-and-context-glossary.md | Generated targets |
| AD-062 | Active recovery queue storms are self-healed by failing stale recovery jobs and cancelling duplicate pending recovery jobs. | dogfood-and-decisions.md | Recovery |
| AD-063 | Default model registry changes require harness-specific benchmark evidence and immutable pinned artifacts. | local-inference.md | Inference |
| AD-064 | Inference routing honors manifest `role.model` tiers before role-name fallback mapping, and missing-model errors name the expected repair path. | local-inference.md | Inference |
| AD-065 | Telemetry triage creates improvement proposals and, when explicitly target-owned or operator-requested, updates `kind: intervention-debt` tickets through the canonical ticket path, deduped by repo, role, target, category, and evidence window. | self-reflective-telemetry.md | Self-improvement |
| AD-066 | Ollama is a first-class catalog and explicit model-swap provider, while zero-config default promotion still requires benchmark evidence, immutable revision, and SHA256. | local-inference.md | Inference |
| AD-067 | Source development installs the command into the Go bin directory before operating target repos; root-level source binaries are treated as stale-binary traps. | dogfood-and-decisions.md | Operator workflow |
| AD-068 | The installed command can update itself with `mars update tool`; release mode accepts only the authenticated signed archive contract and durable replace-or-restore transaction, while source checkout update remains the supported route until approved cutover. | release-versioning.md | Release |
| AD-069 | `update` is the unified CLI verb for the installed tool and deployed target harness. | release-versioning.md | Release |
| AD-070 | `mars update check` reports tool and target harness version drift, writes JSON for automation, and feeds doctor warnings without mutating state. | release-versioning.md | Release |
| AD-071 | Stale active exec plans are intervention debt; they must be corrected with a current operating plan and mechanical hygiene checks. | self-improvement.md | Self-improvement |
| AD-072 | A-F quality scores are repo artifacts; source and initialized target repos carry `docs/QUALITY_SCORE.md` until deterministic score export owns the refresh loop. | self-reflective-telemetry.md | Self-improvement |
| AD-073 | Exec plans follow a ticket-like lifecycle with exactly one active plan; waiting plans live in a prioritized backlog with dependency, blocker, and related-ticket metadata, while historical plans live in superseded lineage. | self-improvement.md | Planning |
| AD-074 | BDD feature contracts define feature completeness; walking skeleton is the implementation strategy; one active plan schedules failing scenarios from active goals through tickets and evidence. | delivery-operating-model.md | Operating model |
| AD-075 | Source install, setup, and update-tool configure the user's shell PATH idempotently across common shells so the installed CLI is zero-config. | release-versioning.md | Setup |
| AD-076 | The harness glossary is mirrored first-class context in source and generated target `AGENTS.md`, with contextual definitions routed through `docs/design-docs/harness-glossary.md`. | mirrored-harness-and-context-glossary.md | Generated targets |
| AD-077 | `tool_create` is a mirrored mutating tool that scaffolds built-in tool files and tests while requiring separate implementation, registration, trust-policy review, and allowlist exposure. | dogfood-and-decisions.md | Tools |
| AD-078 | Superseded by AD-313/T-065: source assets used the retired tag-driven bespoke publisher; retained consumers migrate under T-066. | release-versioning.md | Release |
| AD-079 | `mars_cli` is a mirrored mutating tool that exposes exhaustive CLI reference and structured execution for foundation and deployed harness operation. | dogfood-and-decisions.md | Tools |
| AD-080 | Tool availability and use cases live in a first-class mirrored tools glossary, and every newly created tool must extend it. | mirrored-harness-and-context-glossary.md | Tools |
| AD-081 | Operating-model changes must be symbiotic with the existing workflow: no handoff gaps, duplicate sources of truth, or inconsistencies with adjacent artifacts, roles, tools, evidence, release, scoring, or self-improvement paths. | delivery-operating-model.md | Operating model |
| AD-082 | Repeated, risky, validation-heavy, or likely-to-recur processes should become formalized tools, mirrored and documented when they apply to both foundation and deployed harnesses. | delivery-operating-model.md | Tools |
| AD-083 | New built-in tools must originate through `tool_create`; bypassing it requires `record_decision` and design-doc rationale before completion. | dogfood-and-decisions.md | Tools |
| AD-084 | Six canonical operating domains are the role-model vocabulary, while explicit manifest roles remain the executable units and may declare optional domain/mode metadata. | harness-operating-model.md | Role model |
| AD-085 | Checked role registries in source and generated targets inventory manifest roles, domains, modes, triggers, tools, trust, guardrails, model routing, scoring signals, and escalation behavior, and doctor checks them against manifests. | harness-operating-model.md | Role registry |
| AD-086 | Significant agent conversations are inputs that must become durable repo artifacts when they change plans, decisions, investigations, quality evidence, or completed-work state. | conversation-as-system-record.md | Documentation discipline |
| AD-087 | Universal mirrored tools are exposed through `mars mcp serve` so MCP-compatible clients and local harness agents can use the built-in registry through a model-provider-agnostic tool mechanism. | dogfood-and-decisions.md | Tools |
| AD-088 | MARS readiness is measured through a repo-visible dogfood matrix and observer-mode Mars supersession benchmark before contributor-mode autonomy is trusted. | dogfood-matrix.md | Dogfood |
| AD-089 | Native Orchestrator surveys are an internal signal source that routes unattended ticket, check, dogfood, no-op, telemetry, score, recovery, and stuck-work state into bounded queue jobs or quarantined foundation telemetry by default, using payload mode, concurrency group, and daily cap metadata. | trigger-orchestration.md | Orchestrator |
| AD-090 | Dispatch-mode orchestration is the generated default: terminal job dispositions route directly when deterministic and return to Orchestrator when synthesis or fallback is needed, while legacy chaining remains supported for existing manifests. | orchestrated-organization-layer.md | Orchestration |
| AD-091 | Generated target manifests seed write-capable bootstrap roles with contributor trust, DB trust overrides still win, and obvious destructive shell deletion operations are blocked before execution. | dogfood-and-decisions.md | Trust and safety |
| AD-092 | Intervention-debt routing classifies tool-policy and blast-radius failures as guardrail blocks and suppresses secondary ticket-gate tickets for the same job after a policy block. | dogfood-and-decisions.md | Telemetry |
| AD-093 | The fast fake-LLM foundation containment gate is release-blocking, dirty worktrees fail before LLM invocation, read-only shell inspection avoids blast-radius noise, deterministic failures stop blind recovery, and repeated intervention updates are bounded. | dogfood-and-decisions.md | Dogfood |
| AD-094 | File count is disabled as a default blast-radius gate, stronger line/deletion/secret/trunk checks remain enforced, and intervention debt no longer preempts ordinary product backlog by default. | dogfood-and-decisions.md | Safety |
| AD-095 | New ticket markdown is owned by `ticket_create`; `file_write` blocks root-level ticket files and new lifecycle ticket files while existing tickets can still be edited for evidence and blockers. | dogfood-and-decisions.md | Tickets |
| AD-096 | Target harnesses have a dry-run kill switch: `mars eject` removes generated repo artifacts and the per-repo database only after explicit apply confirmation. | dogfood-and-decisions.md | Operator workflow |
| AD-097 | Business logic is first-class BDD: every product rule, workflow branch, state transition, validation, permission, scoring/routing rule, or user-visible outcome belongs step by step under `docs/features/`. | delivery-operating-model.md | Operating model |
| AD-098 | No stale documentation: code changes carry top-of-file `MarsDocSync` metadata with a `docs:` array listing associated docs, and those docs are updated in the same change or explicitly checked as still current. | delivery-operating-model.md | Documentation discipline |
| AD-101 | Code documentation map: source prefixes map to architecture docs and BDD feature contracts, and `docsync audit` verifies `MarsDocSync` metadata across source roots. | code-documentation-map.md | Documentation discipline |
| AD-102 | Documentation Sync is a universal operating model: agents read changed-file `MarsDocSync` docs, classify documentation impact, update or verify associated docs, run docsync evidence, and mirror the model into generated targets. | documentation-sync-architecture.md | Documentation discipline |
| AD-103 | CLI tool/skill sync is a foundational operating model: every CLI command or flag change updates `mars_cli`, repo-shortcut routing, generated target doctrine, and any affected skills before completion. | cli-tool-skill-sync.md | Operating model |
| AD-104 | Foundation telemetry uses opt-in anonymous aggregate reports through a pluggable collector: local SQLite for dogfood, hosted Postgres-compatible storage later. | self-reflective-telemetry.md | Telemetry |
| AD-105 | Foundation agents use canonical persona manuals for ownership, feedback, and handoff; Go structs in `internal/personas` render checked docs and prompt Personal Guides. | harness-operating-model.md | Roles |
| AD-106 | Structured disposition packets travel through Orchestrator: dispatch triggers carry routing-safe source dispositions, and Orchestrator-owned routing honors validated structured targets. | harness-operating-model.md | Roles |
| AD-107 | Workspace hygiene gates generated dependency/build churn before model work and package-manager mutation; dependency setup uses `dependency_sync` instead of raw `shell_exec`. | guardrails.md | Safety |
| AD-108 | Agents fetch and fast-forward from `origin/main` before non-trivial work, then push validated commits and release tags to remote trunk as soon as they are ready. | delivery-operating-model.md | Operating model |
| AD-109 | Fresh target lifecycle prioritizes product progress before intervention debt: runtime failures quarantine to telemetry by default, score export ticket creation is opt-in, repo-local DB/log artifacts are rejected, bootstrap seeding is idempotent, containment failures stop dispatch loops, and generated F-001 is a product walking skeleton. | dogfood-and-decisions.md | Lifecycle |
| AD-110 | MARS source improvements that claim lifecycle, orchestration, generated-target, model/provider, scoring, safety, dashboard/control-plane, or update/release gains must include a representative live target check such as `demo-123` or an explicit blocker with replay steps. | delivery-operating-model.md | Operating model |
| AD-111 | Fresh bootstrap technical planning is bounded: CTO creates or confirms one current-scenario implementation ticket before handoff, defers broad audits until product progress exists, and `ticket_create` dedupes independent fan-out for the same BDD scenario unless `depends_on` is explicit. | delivery-operating-model.md | Lifecycle |
| AD-112 | Successful dispatch handoffs preserve clean target state: `file_write` blocks duplicate feature contracts with the same feature ID, and non-Orchestrator roles must commit repo-visible work before successful terminal dispositions. | delivery-operating-model.md | Lifecycle |
| AD-113 | Dispatch routing normalizes small canonical role aliases such as `cto`, `release`, and `dependency` to executable generated manifest role keys before falling back to Orchestrator. | delivery-operating-model.md | Orchestration |
| AD-114 | Failed Orchestrator dispatch falls forward from the original source disposition when deterministic routing exists, or records a stopped decision without enqueueing Orchestrator again. | delivery-operating-model.md | Orchestration |
| AD-115 | Ticket lifecycle moves are a bounded blast-radius deletion exception: the deletion side is ignored only when the same ticket ID appears in another ticket lifecycle directory in the same diff. | guardrails.md | Safety |
| AD-116 | Engineer dispatch requires an open ordinary product ticket; no-ticket implementation handoffs are rewritten to CTO ticket shaping rather than enqueueing Engineer. | delivery-operating-model.md | Orchestration |
| AD-117 | Engineer ticket-gate failures enqueue one bounded Engineer repair job with the gate error, and repeated repair failures stop without Orchestrator or recursive repair dispatch. | delivery-operating-model.md | Orchestration |
| AD-118 | Dispatch protocol failures, such as missing `job_disposition_record`, are recorded as telemetry and stop instead of routing through Orchestrator. | delivery-operating-model.md | Orchestration |
| AD-119 | Completed Engineer tickets cancel stale pending ticket-owner survey jobs whose referenced tickets are no longer eligible in-progress work. | delivery-operating-model.md | Orchestration |
| AD-120 | Approved or completed review handoffs move forward through the product validation chain instead of routing backward to an earlier reviewer for the same completed review chain. | delivery-operating-model.md | Orchestration |
| AD-121 | Runtime-managed `.harness/learnings.yaml` metadata does not block successful non-Orchestrator dispatch dispositions by itself; product, ticket, documentation, and source dirty paths still require a commit before clean handoff. | delivery-operating-model.md | Lifecycle |
| AD-122 | COO is planning-only before CTO ticketing: `file_write` is limited to planning artifacts, mutating `shell_exec` is blocked, and generated COO defaults no longer expose shell access. | delivery-operating-model.md | Lifecycle |
| AD-123 | A completed Engineer source disposition with no remaining open ordinary product ticket routes to QA before any further CTO planning or implementation handoff. | delivery-operating-model.md | Orchestration |
| AD-124 | Review `changes_requested` handoffs reuse an existing ordinary product ticket for Engineer rework even when the ticket currently lives in done or in-review, while fresh no-ticket implementation still routes to CTO. | delivery-operating-model.md | Orchestration |
| AD-125 | Dispatch-mode jobs require terminal-tool recovery: prose-only completion triggers an in-band prompt for `job_disposition_record`, while repeated misses still stop as foundation telemetry without Orchestrator or target-debt recovery. | delivery-operating-model.md | Orchestration |
| AD-126 | QA must inspect the repository before liveness blocking; missing trigger-provided source context retries QA inspection instead of routing backward into planning. | delivery-operating-model.md | Orchestration |
| AD-127 | Inline `<tool_call>name{...}</tool_call>` local-model output is parsed as a real tool call, including terminal dispositions, instead of being treated as prose. | delivery-operating-model.md | Agent runtime |
| AD-128 | After QA and Security approve a fresh product slice, automatic progression routes to Dogfood before dependency/release governance, and stops when no forward product-validation owner remains. | delivery-operating-model.md | Orchestration |
| AD-129 | Runtime-managed `.harness/learnings.yaml` is auto-committed when it is the only dirty target path after a server job, while mixed product dirty state remains visible and guarded. | delivery-operating-model.md | Lifecycle |
| AD-130 | Deterministic product handoffs bypass Orchestrator while preserving role validation, ticket prerequisites, review progression, loop guards, decision records, and typed dispatch triggers. | delivery-operating-model.md | Orchestration |
| AD-131 | CEO file writes are constrained to strategy artifacts, and `no_work` dispositions with an explicit next need still route the next owner. | delivery-operating-model.md | Lifecycle |
| AD-132 | QA approval after completed Engineer work advances to forward product validation instead of reapplying the Engineer pre-review ticket guard and looping QA. | delivery-operating-model.md | Orchestration |
| AD-133 | Generated QA review starts with read-only repo-inspection tools, has `git_status` and `git_diff`, and uses the reasoning tier so review cannot quietly complete as fast-tier prose. | delivery-operating-model.md | Orchestration |
| AD-134 | Feature tickets cannot be moved or saved under `docs/tickets/done/` until BDD evidence fields are populated; tool policy blocks the move before the post-run ticket gate needs a repair job. | delivery-operating-model.md | Lifecycle |
| AD-135 | Non-Orchestrator runtime failures such as `max_turns` stop as foundation telemetry instead of routing through Orchestrator; ticket lifecycle completion must use atomic moves, feature scenario IDs must be unique, and `ticket_create` strips duplicate title headings. | delivery-operating-model.md | Lifecycle |
| AD-136 | Dogfood validation is observation-first: it can write bounded evidence reports and target-owned findings, but cannot mutate product/package/config/harness files to make validation pass. | delivery-operating-model.md | Validation |
| AD-137 | Engineer product mutation requires a claimed in-progress product ticket when ordinary backlog work exists, and successful Engineer dispositions require the named ticket to live in `docs/tickets/done/`. | delivery-operating-model.md | Lifecycle |
| AD-138 | Source lifecycle stabilization uses a continuous live demo improvement loop: run a clean representative target, review findings, implement one or two bounded source actions, rerun, merge or fast-forward the confirmed fix to trunk, push it to the remote, and claim improvement only from rerun evidence. | delivery-operating-model.md | Operating model |
| AD-139 | Foundation and deployed harness architecture separates source doctrine, runtime substrate, generated target doctrine, target project ownership, feedback routing, tool/skill authority, and source-only release mechanics. | foundation-deployed-harness-architecture.md | Operating model |
| AD-140 | Superseded by T-065/F-018: the skill described the retired bespoke publisher and now governs publication-disabled source snapshots. | skill-evolution.md | Skills |
| AD-141 | Superseded by AD-313/T-065: the source-only skill now governs pinned publication-disabled GoReleaser/Syft snapshots while targets own their producer. | release-versioning.md | Release |
| AD-142 | Repo-local build artifact cleanup is a bounded removal exception: agents may remove an untracked root-level binary named after the repo or Go module, and blast-radius errors name the safe cleanup command while ordinary deletion remains blocked. | guardrails.md | Safety |
| AD-143 | Fresh bootstrap planning reuses the canonical existing `docs/features/F-NNN*.md` path; CEO names it for COO, and COO rewrites starter scenarios in place instead of creating duplicate feature contracts. | delivery-operating-model.md | Lifecycle |
| AD-144 | Long-running app validation is managed by `shell_exec background:true`: shell-background `&` is rejected, startup exits return tool errors, and generated Engineer guidance forbids `cmd & PID=$!` process management. | delivery-operating-model.md | Tools |
| AD-145 | Validation build outputs stay outside target repos: `go build` without `-o` and `go build -o <path>` inside the target repo are rejected before execution, and malformed shell calls surface before dirty-diff masking. | delivery-operating-model.md | Safety |
| AD-146 | Bare port tokens such as `:8080` are invalid validation commands: `shell_exec` rejects them before process execution and redirects roles to real server commands plus curl probes. | delivery-operating-model.md | Tools |
| AD-147 | Scratch validation stays out of the target root: new root-level validation shell scripts are blocked, and external `timeout`/`gtimeout` commands are replaced by tool `timeout_seconds` or managed `background:true` probes. | delivery-operating-model.md | Tools |
| AD-148 | Background process cleanup kills wrapper descendants as well as the tracked process group, including targeted `kill <tracked-pid>` cleanup, so `go run` child servers do not leak across jobs or live canary replays. | delivery-operating-model.md | Tools |
| AD-149 | Empty `shell_exec` argv and single `:` no-op calls return completion guidance with tracked background PIDs instead of becoming guardrail-loop failures. | delivery-operating-model.md | Tools |
| AD-150 | Successful implementation, review, validation, and release handoffs are blocked while `docsync_audit` has findings, deployed target repos are not forced to cite foundation-only expected docs, and policy-blocked external `timeout` commands classify as guardrail blocks instead of retryable tool timeouts. | delivery-operating-model.md | Lifecycle |
| AD-151 | No-op `shell_exec` calls now fail with completion guidance, and `file_write` rejects source/test writes that lack valid top-of-file `MarsDocSync` docs metadata before source files enter the worktree. | delivery-operating-model.md | Tools |
| AD-152 | Shell tool policy decodes `shell_exec` arguments through the same malformed-argv normalization path as execution, so ownership exceptions such as backlog-to-in-progress ticket claims are not blocked by JSON-string argv drift. | delivery-operating-model.md | Tools |
| AD-153 | Engineer shell execution is claim-first when backlog product work exists, and dispatch dispositions normalize simple list-as-string evidence fields before validation. | delivery-operating-model.md | Lifecycle |
| AD-154 | Likely long-running server/watch validation commands are blocked in foreground `shell_exec` and must use managed `background:true` plus a separate readiness probe. | delivery-operating-model.md | Tools |
| AD-155 | Security review uses bounded terminal evidence after Engineer and QA: inspect, scan, docsync, test, at most one managed runtime smoke, then write the audit and record disposition. | delivery-operating-model.md | Lifecycle |
| AD-156 | The next dashboard generation uses a TanStack Start sidecar behind the Go dashboard gateway, requires external Node `24.x` and `pnpm@11.1.1`, protects all routes with local-admin auth, uses nonblocking concurrent read APIs, and treats GitHub-derived DORA and source-change proposals as optional guarded integrations. | dashboard.md | Dashboard epic |
| AD-157 | Security review reports implementation, evidence, and documentation remediation back to Engineer instead of patching product files, and root scratch validation probes such as `debug.go` are blocked before they enter target repos. | delivery-operating-model.md | Lifecycle |
| AD-158 | Security findings are grounded in current evidence rather than speculative hardening, and Engineer review rework stops after the requested evidence is proven and committed. | delivery-operating-model.md | Lifecycle |
| AD-159 | Engineer implementation is bounded by the selected ticket and BDD contract, with exploratory edge cases recorded as follow-up evidence instead of same-run churn. | delivery-operating-model.md | Lifecycle |
| AD-160 | Engineer closes a feature ticket after required acceptance evidence passes before packaging or distribution exploration, and `shell_exec` blocks repo-local Go build outputs inside shell command segments before artifacts are created. | delivery-operating-model.md | Lifecycle |
| AD-161 | Dogfood-created target finding tickets must be committed and handed off before further validation or duplicate ticket creation can continue. | delivery-operating-model.md | Validation |
| AD-162 | QA and Security approval requires successful in-job validation evidence, Dogfood finding creation ends further same-run validation until disposition, argv accepts literal newline arguments, and evidenced enabler tickets can close without feature metadata. | delivery-operating-model.md | Validation |
| AD-163 | Feature contract scenario headings must use the same feature ID as the contract file path, preventing `F-002-SNNN` scenarios from being embedded in `docs/features/F-001*.md` and stalling fresh ticket creation. | delivery-operating-model.md | Lifecycle |
| AD-164 | Engineer shell execution converges after successful validation and an implementation commit by blocking further exploratory shell calls until the in-progress product ticket moves to done, while context pruning now removes old tool-call arguments before overflow. | delivery-operating-model.md | Lifecycle |
| AD-165 | Review rework must reopen done or in-review product tickets before Engineer mutates product files or runs validation shell work, and the post-validation shell gate only fires after a clean committed implementation. | delivery-operating-model.md | Lifecycle |
| AD-166 | Repeated Engineer no-op `shell_exec` calls after successful validation and dirty ticket work are treated as a loop boundary that redirects to status, commit, ticket lifecycle completion, and terminal disposition. | delivery-operating-model.md | Lifecycle |
| AD-167 | QA has a bounded validation shell surface, and `<validation-root>` binaries are trusted only after the same role session builds them before execution. | delivery-operating-model.md | Validation |
| AD-168 | Direct runtime commands such as language run entrypoints, package start scripts, and bounded smoke probes count as validation evidence after successful exit, allowing Engineer convergence to close tickets after product behavior is proven. | delivery-operating-model.md | Validation |
| AD-169 | Expected non-zero runtime probes can serve as negative-path review evidence without poisoning approval, while failing builds and tests still block QA/Security approval. | delivery-operating-model.md | Validation |
| AD-170 | Post-validation Engineer shell blocks name the required non-shell ticket evidence sequence before the final lifecycle move, reducing repeated empty shell loops after useful implementation work is committed. | delivery-operating-model.md | Lifecycle |
| AD-171 | Review approval blocks unexpected runtime validation failures, while intentional non-zero error-path probes must declare `shell_exec expected_exit_code`; external temp validation cleanup does not force ticket rework. | delivery-operating-model.md | Validation |
| AD-172 | Review validation failures stop further shell validation and exit through structured `changes_requested`, dispatch jobs get one terminal-tool grace turn at the budget edge, and external Go validation builds must use tracked `<validation-root>` paths. | delivery-operating-model.md | Validation |
| AD-173 | Reviewers may correct one exact expected-negative runtime probe by rerunning it with matching `shell_exec expected_exit_code`, while failing builds/tests and uncorrected runtime failures still force structured rework. | delivery-operating-model.md | Validation |
| AD-174 | Product lifecycle completion is blocked while current-job runtime validation failures remain unrepaired, and the terminal grace turn may execute only the configured terminal disposition tool. | delivery-operating-model.md | Lifecycle |
| AD-175 | Engineer cannot clear an unexpected runtime validation failure by retroactively adding `expected_exit_code`; only QA/Security get that one-time review-procedure correction. | delivery-operating-model.md | Validation |
| AD-176 | Engineer runtime validation failures require implementation rework before further runtime probes, and the exact failed command must pass before product completion can continue. | delivery-operating-model.md | Validation |
| AD-177 | Engineer may correct an obvious missing-argument runtime probe with exact `expected_exit_code`, while positive acceptance failures still require implementation rework. | delivery-operating-model.md | Validation |
| AD-178 | Direct runtime validation that prints error-shaped stderr is failed evidence even with exit code 0, and only a clean exact rerun repairs the blocker. | delivery-operating-model.md | Validation |
| AD-179 | Repeated Engineer no-op shell calls after ticket claim but before implementation are blocked and routed to ticket/feature reading plus product `file_write`. | delivery-operating-model.md | Lifecycle |
| AD-180 | Unresolved runtime-failure guidance explicitly tells Engineer to correct intentional missing-argument probes with exact `expected_exit_code`, while keeping positive acceptance repair strict. | delivery-operating-model.md | Validation |
| AD-181 | Failed `ticket_create` or ticket-file bypass attempts stay unresolved until a successful `ticket_create` follows, so planning roles cannot record completed progress without a real backlog ticket. | delivery-operating-model.md | Lifecycle |
| AD-182 | Missing-argument runtime failures store the exact `shell_exec` correction and block unrelated Engineer mutations until that correction runs or an honest blocked disposition is recorded. | delivery-operating-model.md | Validation |
| AD-183 | External `<validation-root>` artifacts record the runtime-edit watermark at build time and must be rebuilt after post-failure source edits before rerun evidence is trusted. | delivery-operating-model.md | Validation |
| AD-184 | Engineer cannot populate in-progress ticket `evidence_links` or `verified_by` until the same job has successful validation evidence. | delivery-operating-model.md | Lifecycle |
| AD-185 | External validation artifact freshness errors name the exact `shell_exec argv` rebuild command so QA/Security can rebuild in-session before rerunning `<validation-root>` probes. | delivery-operating-model.md | Validation |
| AD-186 | Go build-output guardrails emit exact corrected `shell_exec argv` commands that preserve the original package target, and exact expected-output examples require automated assertions. | delivery-operating-model.md | Validation |
| AD-187 | Missing-input expected-exit repro guards unlock implementation edits after a failed correction attempt while still blocking completion, and generated target guidance derives names from the target product instead of foundation defaults. | delivery-operating-model.md | Validation |
| AD-188 | One successful exact runtime rerun clears every unmatched same-command failure count in the current job so repeated failures do not leave stale outstanding blockers. | delivery-operating-model.md | Validation |
| AD-189 | Reviewer shell execution is validation-only, ticket done moves require non-ticket product changes to be committed first, and Orchestrator must route from live lifecycle state rather than ticket README examples. | delivery-operating-model.md | Lifecycle |
| AD-190 | Required terminal-tool jobs get one circle-grace reminder, and reviewer no-op shell loops after validation route to structured disposition instead of losing product progress to `circle_detected`. | delivery-operating-model.md | Validation |
| AD-191 | Unresolved Engineer runtime acceptance failures freeze unrelated shell paths and product commits until the exact failed command is repaired, while still allowing stale `<validation-root>` artifact rebuilds. | delivery-operating-model.md | Validation |
| AD-192 | Engineer ticket evidence update failures do not become ticket-creation debt, preserving ticket-create false-progress blocks without poisoning later valid implementation handoffs. | delivery-operating-model.md | Lifecycle |
| AD-193 | Review no-op recovery is terminal-only after successful validation, missing Go tests route QA to `changes_requested`, and non-ticket-owning planners hand off ticket breakdown instead of creating tickets through alternate paths. | delivery-operating-model.md | Validation |
| AD-194 | Engineer failing test/build evidence freezes runtime side paths, ticket evidence, ticket completion, successful disposition, and product commits until the exact failing command passes after source/test repair. | delivery-operating-model.md | Validation |
| AD-195 | CTO technical planning may create tickets and bounded architecture rationale, but product implementation, package/module, README usage, source, test, build, config, and root product-file writes belong to ticket-backed Engineer delivery. | delivery-operating-model.md | Lifecycle |
| AD-196 | Engineer test/build repair is same-lane rather than exact-command-only: source/test/fixture/build-config repairs and focused validation are allowed, while runtime probes, helper scripts, ticket evidence, completion, disposition, and commits stay blocked until validation passes. | delivery-operating-model.md | Validation |
| AD-197 | Simple `cd <dir> && <test-or-build command>` shell commands are recognized as same-lane validation for Engineer repair, while arbitrary shell control syntax remains blocked as a workaround path. | delivery-operating-model.md | Validation |
| AD-198 | QA and Security clean review evidence now forces a terminal-only `job_disposition_record` response with a short grace timeout, preventing review stages from spending another long model turn after enough evidence is gathered. | delivery-operating-model.md | Validation |
| AD-199 | QA and Security validation-procedure mistakes such as `go build cmd/<name>` without `./` or root `.` builds for `cmd/*` CLIs are tracked separately from target product failures, allowing corrected review validation without false implementation rework. | delivery-operating-model.md | Validation |
| AD-200 | `shell_exec` normalizes only the safe argv-shaped `cd <dir> && <test-or-build>` validation pattern into `shell_command`, preventing local-model formatting drift from poisoning nested-module test validation while keeping arbitrary shell syntax rejected. | delivery-operating-model.md | Tools |
| AD-201 | Obvious CLI input-validation runtime probes, including missing required input and deliberately invalid input, count as expected negative-path validation when output shows normal validation text and no crash markers. | delivery-operating-model.md | Validation |
| AD-202 | Engineer Go validation-procedure mistakes such as missing `./` on repo-relative package targets are tracked separately from product build failures, allowing corrected validation without meaningless source edits. | delivery-operating-model.md | Validation |
| AD-203 | Surplus CLI argument probes count as expected negative-path runtime evidence when output clearly reports too many arguments and no crash markers are present. | delivery-operating-model.md | Validation |
| AD-204 | Engineer test/build repair may remove same-job test-like files written after the failure, while unmarked tests, product source, and recursive cleanup remain blocked. | delivery-operating-model.md | Validation |
| AD-205 | Review terminal-evidence reminders reject one missed non-terminal tool in-band before failing repeated misses, preserving completed QA/Security reviews without unbounded inspection. | delivery-operating-model.md | Validation |
| AD-206 | Engineer test/build repair writes are constrained to the failed package scope when a narrow Go package target is known, preventing alternate root implementations during repair. | delivery-operating-model.md | Validation |
| AD-207 | Release tag creation is blocked unless the tag matches VERSION, the worktree is clean, HEAD is the release-note commit, and any explicit tag target resolves to that HEAD. | release-versioning.md | Release |
| AD-208 | Runtime current-date grounding is injected through a non-droppable `## RUN METADATA` context section so agents date evidence, reports, release entries, and ticket timestamps from the actual run instead of model memory or examples. | context-efficiency.md | Context |
| AD-209 | Engineer test/build repair may remove duplicate/generated test files created or rewritten earlier in the same job, while pre-existing tests and source deletion remain blocked. | delivery-operating-model.md | Validation |
| AD-210 | Review terminal convergence waits for `docsync_audit` evidence before forcing `job_disposition_record`, avoiding a QA/Security contradiction between docsync doctrine and terminal-only runtime correction. | delivery-operating-model.md | Validation |
| AD-211 | Review terminal convergence waits for a successful test command when test files exist, so build-only evidence cannot prematurely force QA/Security disposition. | delivery-operating-model.md | Validation |
| AD-212 | Review no-op recovery uses the same evidence gates as approval, so blocked no-op placeholders cannot force terminal disposition before tests or docsync have passed. | delivery-operating-model.md | Validation |
| AD-213 | Agent jobs must run MARS CLI workflows through `mars_cli`; direct `shell_exec mars ...` is blocked so deployed roles do not resolve stale installed binaries instead of the active harness executable. | delivery-operating-model.md | Tools |
| AD-214 | Startup cleanup preserves SQLite `-wal` and `-shm` sidecars and lets SQLite recover/checkpoint them, preventing retry-after-bind-failure cleanup from discarding queued bootstrap state. | pipeline-engine.md | Persistence |
| AD-215 | Unresolved Engineer test/build repair guardrails repeat the latest failing output and tell Engineer to edit implementation, not weaken a contract-matching test, before rerunning same-lane validation. | guardrails.md | Validation |
| AD-216 | Missing Go module bootstrap is treated as a bounded Engineer test/build repair action only when the latest failure output proves `go mod init` is required and `go.mod` is absent. | delivery-operating-model.md | Validation |
| AD-217 | Raw `go get` is dependency mutation and same-job test cleanup is limited to duplicate/generated-test failures, preserving assertion evidence during Engineer repair. | guardrails.md | Validation |
| AD-218 | Engineer no-op shell placeholders after successful validation and dirty work are blocked immediately with tracked-PID cleanup, commit, ticket closure, push, and disposition guidance. | delivery-operating-model.md | Validation |
| AD-222 | Browser JavaScript target tickets keep deployed target shape: Phaser briefs without an explicit Go backend cannot prescribe Go CLI paths, `go.mod`, or `cmd/*`, and completion requires local package/build evidence instead of CDN-only static delivery. | delivery-operating-model.md | Lifecycle |
| AD-223 | Browser-framework review evidence must include a real build command and product-state smoke rather than no-op build scripts or HTTP 200 reachability alone. | delivery-operating-model.md | Validation |
| AD-224 | Release-bound dispatch waits for open product tickets and uncovered generated feature scenarios, routing Engineer or CTO before Release Manager when product work remains. | delivery-operating-model.md | Lifecycle |
| AD-225 | Explicit product brief capabilities must be represented in generated feature scenarios or deliberately descoped before COO handoff or CTO ticket creation. | delivery-operating-model.md | Lifecycle |
| AD-226 | Browser-framework Engineer completion is blocked before QA when build evidence is syntax-only, local module imports are not exported, classic script tags load module syntax, or Phaser scene context is misused. | delivery-operating-model.md | Validation |
| AD-227 | Engineer max-turns with an ordinary in-progress product ticket enqueue one bounded product-continuation job, and browser-framework source inspection catches local exports used without imports. | delivery-operating-model.md | Lifecycle |
| AD-228 | Browser validation procedure mistakes such as `node --check index.html` are blocked or classified separately from product runtime failures, and Phaser package/entrypoint writes fail early when they lack local dependencies, real build scripts, or use CDN-only runtime shape. | delivery-operating-model.md | Validation |
| AD-229 | COO starter-placeholder guards reject actual scaffold markers without treating durable BDD vocabulary such as product rules, workflow branches, and state transitions as placeholder text by itself. | delivery-operating-model.md | Lifecycle |
| AD-230 | Phaser/Vite configs cannot import browser runtime or `src/*` game modules, and unresolved build guardrails compact repeated failing output to avoid context overflow during repair loops. | delivery-operating-model.md | Validation |
| AD-231 | Engineer test/build repair lanes treat durable test files under test roots or with conventional test/spec suffixes as valid repair writes, while root scratch probes and unrelated files remain blocked. | delivery-operating-model.md | Validation |
| AD-232 | Browser game builds must use real bundling/static validation instead of copy-only scripts, generated target ignores include common frontend output dirs, and Phaser modules must import Phaser where they reference it. | delivery-operating-model.md | Validation |
| AD-233 | Browser-game smoke validation allows bounded language eval arguments such as `node -e`, and explicit brief requirements cannot hide under generic `Out of Scope` text without descoping rationale. | delivery-operating-model.md | Validation |
| AD-234 | Browser-framework Vite config must not externalize Phaser/runtime dependencies, and smoke guardrails provide a literal `node -e` argv command for bounded product-state assertions. | delivery-operating-model.md | Validation |
| AD-235 | Feature tickets must include the earliest uncovered BDD scenario, Phaser app scripts avoid reserved MARS ports/static source servers, and Phaser source writes block CDN/global/recursive game-construction shapes before context-overflow loops. | delivery-operating-model.md | Validation |
| AD-236 | Wrapped brief capability lists are parsed as operator intent, and post-validation convergence still allows missing browser build or product-smoke evidence commands before ticket closure. | delivery-operating-model.md | Validation |
| AD-237 | Product capability guards ignore validation-evidence clauses and treat keyboard-control language as movement coverage during planning checks. | delivery-operating-model.md | Validation |
| AD-238 | Out-of-scope capability checks are line-aware, so advanced-only qualifiers do not falsely descope basic capabilities already covered by scenarios. | delivery-operating-model.md | Validation |
| AD-239 | Engineer circle-detected jobs with an active product ticket enqueue one bounded product-continuation job instead of stopping with dirty partial product work. | delivery-operating-model.md | Lifecycle |
| AD-240 | Fresh bootstrap can seed a small ordered product-ticket batch, and browser-smoke validation helper issues cannot be routed back to target Engineer as implementation rework when source inspection is clean. | delivery-operating-model.md | Lifecycle |
| AD-241 | Browser-framework QA validation setup failures cannot force target rework, and CTO first-slice handoff now prioritizes one executable ticket before post-proof backlog expansion. | delivery-operating-model.md | Lifecycle |
| AD-242 | Capability extraction strips generic category prefixes before colon-delimited product lists so strategy prose does not create phantom scenario requirements. | delivery-operating-model.md | Lifecycle |
| AD-243 | Feature ticket creation rejects already-covered BDD scenarios, and Engineer jobs must commit and hand off one completed product ticket before claiming another. | delivery-operating-model.md | Lifecycle |
| AD-244 | Browser validation helper paths are excluded from product Phaser source lifecycle checks while shipped app source and config remain guarded. | delivery-operating-model.md | Validation |
| AD-245 | Explicit product capabilities must appear in scenario schedule entries or scenario headings so COO cannot collapse a requested product into one broad runnable/inspectable scenario. | delivery-operating-model.md | Lifecycle |
| AD-246 | CTO implementation handoff counts early product scenarios, not evidence-only or governance-only process scenarios, when deciding whether the bootstrap backlog is ready for Engineer. | delivery-operating-model.md | Lifecycle |
| AD-247 | CTO ticket creation can infer missing BDD scenario IDs from the pending post-proof handoff scenario batch after the gate names the next product scenarios. | delivery-operating-model.md | Tools |
| AD-248 | Planner roles may inspect with read-only shell commands, but mutating `shell_exec` is blocked so strategy, planning, ticketing, dependency, and implementation ownership cannot be bypassed. | delivery-operating-model.md | Tools |
| AD-249 | Product capability extraction treats Markdown bullets as separate statements and keeps active-goal non-goals plus operational build/install constraints out of required product scenario coverage. | delivery-operating-model.md | Lifecycle |
| AD-250 | Product-name and modifier words do not block natural scenario titles when the actual requested behavior words are visible in the scenario outline. | delivery-operating-model.md | Lifecycle |
| AD-251 | High-score, persistence, and `beyond ...` out-of-scope wording is treated as advanced extension scope, not as descoping covered basic behavior. | delivery-operating-model.md | Lifecycle |
| AD-252 | Live-loop, dogfood, telemetry, review, and operator findings must be classified as foundation-owned, deployed-owned, or mixed before tickets or fixes are created, so fixes land at the right layer and generalize beyond one demo stack. | delivery-operating-model.md | Operating model |
| AD-253 | Reviewer HTTP probes that fail before a server is listening are validation-procedure failures, and Engineer review rework must reopen the dispatch-named ticket instead of scanning older done tickets. | delivery-operating-model.md | Validation |
| AD-254 | CTO duplicate ticket failures do not poison implementation handoff when the ticket lifecycle already covers the required early product scenario batch. | delivery-operating-model.md | Lifecycle |
| AD-255 | Capability matching treats generic product piece wording and concrete game-piece nouns as equivalent when validating product scenario coverage. | delivery-operating-model.md | Lifecycle |
| AD-256 | Duplicate feature contract path guidance is role-aware, so CEO hands off canonical feature updates to COO instead of following contradictory recovery text. | delivery-operating-model.md | Lifecycle |
| AD-257 | Browser-framework entry validation treats missing `node --check` targets as procedure failures and checks actual Phaser callback bodies before blocking recursive game construction. | delivery-operating-model.md | Validation |
| AD-258 | Product capability coverage and CTO handoff gates follow active feature contracts, ignoring superseded walking-skeleton contracts except as bootstrap fallback. | delivery-operating-model.md | Lifecycle |
| AD-259 | Browser-framework Node eval probes that load browser-only modules and fail on missing browser globals are validation-procedure failures, not product runtime blockers. | delivery-operating-model.md | Validation |
| AD-260 | New repo-root validate/smoke/probe helper files are blocked as scratch validation noise; durable browser-framework helpers must live under `scripts/` or `tests/`. | delivery-operating-model.md | Validation |
| AD-261 | Successful Engineer `dependency_sync` counts as a repair action for unresolved test/build failures so missing build dependencies can be followed by same-lane validation reruns. | delivery-operating-model.md | Validation |
| AD-262 | Browser-framework tickets cannot prescribe CDN runtime acceptance, reviewer smoke blockers print the canonical smoke command, and QA/Security may stop tracked background validation PIDs. | delivery-operating-model.md | Validation |
| AD-263 | Generic summary labels such as core gameplay mechanics are ignored as standalone capability keywords while concrete product behaviors remain required. | delivery-operating-model.md | Lifecycle |
| AD-264 | Generic controls wording alone no longer satisfies movement coverage, so alternate input exclusions such as mobile touch controls do not descope keyboard movement. | delivery-operating-model.md | Lifecycle |
| AD-265 | Browser-framework Engineer jobs stop further shell exploration after same-job build and product-smoke evidence pass while dirty work remains, forcing commit, ticket evidence, done move, and disposition. | delivery-operating-model.md | Validation |
| AD-266 | Active feature-ticket scenario overlap dedupes Dogfood findings, review roles go straight to canonical browser-framework evidence, Security avoids broad shell secret scans, and Orchestrator preserves lifecycle ticket paths. | delivery-operating-model.md | Lifecycle |
| AD-267 | After browser-framework package build passes but before browser-product smoke passes, Engineer shell validation is limited to build reruns, canonical product smoke, and tracked PID cleanup so Node-only bundle probes cannot replace mounted UI evidence. | delivery-operating-model.md | Validation |
| AD-268 | Out-of-scope explanation prose and advanced-only extensions no longer descope covered basic product capabilities such as line clearing or score tracking. | delivery-operating-model.md | Lifecycle |
| AD-269 | Capability matching ignores generic glue words such as include/including, show/display, and detection while preserving concrete behavior requirements. | delivery-operating-model.md | Lifecycle |
| AD-270 | Enhancement-only Out-of-Scope lines such as animations for movement or line clearing do not descope covered basic gameplay behavior. | delivery-operating-model.md | Lifecycle |
| AD-271 | COO current-failing-scenario recovery updates the single active exec plan instead of creating sibling active plan files. | delivery-operating-model.md | Lifecycle |
| AD-272 | Readable outcome glue such as see/useful/usable/playable does not become a required product capability when the concrete behaviors are already broken out. | delivery-operating-model.md | Lifecycle |
| AD-273 | Demo evidence remains a traceability anchor and does not become product-specific foundation doctrine; product-label tokens are stripped dynamically instead of added as global stopwords. | delivery-operating-model.md | Lifecycle |
| AD-274 | The source-only `foundation-maintainer` role and vendor-neutral AI client adapters let foundation work consume canonical doctrine without mirroring source roles into deployed harnesses. | harness-operating-model.md | Operating model |
| AD-275 | CTO implementation handoff gates follow the active operating plan feature before older starter or historical feature contracts. | delivery-operating-model.md | Lifecycle |
| AD-276 | The empty pipeline-learnings standing tracker is retired; recurring failure learnings live as delivery-operating-model ADs, validation reports, and deterministic remediation recipes instead of a parallel ledger. | self-improvement.md | Docs hygiene |
| AD-277 | Completed tracking snapshots wholly superseded by living artifacts are deleted; prompt-port-status retired with MH-025 as the historical record and quickstart reconciled against the current CLI surface. | self-improvement.md | Docs hygiene |
| AD-278 | Quality-score exports follow a defined cadence (after validation-run batches, before quality claims, per release-note batch) and grade regressions gate completion claims until explained; hook/schedule automation is recorded follow-up work. | self-reflective-telemetry.md | Quality |
| AD-279 | The single-binary/no-Node constraint is scoped to the core runtime; the TanStack control plane is an optional operator-installed sidecar, T-010's restyle is absorbed by the epic, and the epic is deferred until T-011 closes. | dashboard.md | Dashboard epic |
| AD-280 | Per-package coverage floors are a ratchet enforced by the local `make check` gate: regressions below floor, unfloored new packages, stale entries, and deleted tests all fail mechanically; floors only move up. | source-quality-gates.md | Quality gates |
| AD-281 | The tool-call parser and list-string/argv normalizers that ingest hostile model output are fuzzed (bounded smoke in `make check`, full fuzzing local), while govulncheck scanning fails closed when the scanner is missing or any scan step fails and names pinned v1.6.0 installation remediation. | source-quality-gates.md | Quality gates |
| AD-282 | Fully superseded by T-066 D1/F-018: standalone release verification and audit commands are retired; repository-owned verification and F-018-S004 own the replacement gates. | release-versioning.md | Release |
| AD-283 | `scores export` breaks convergence failures (circle detection, max-turn/max-tool stops, no-op outcomes) and guardrail block rates out per repo/role in `docs/QUALITY_SCORE.md` from existing trace and outcome tables, with a clean-window signal instead of implied health. | self-reflective-telemetry.md | Quality |
| AD-284 | Source-change classes (tool policy, role guidance, orchestration, release flow, scanner/generated doctrine, model behavior, export rendering, docs-only) gate minimum AD-138 archetype replays before lifecycle claims; blocked replays leave the claim unconfirmed with a recorded replay command. | validation-matrix-gating.md | Validation |
| AD-285 | Validation evidence uses a fixed recording contract: `docs/validation/reports/YYYY-MM-DD-<target>-<purpose>.md` paths, required run fields, explicit pass criteria, and ticket/report cross-references. | validation-matrix-gating.md | Validation |
| AD-286 | The delivery lifecycle is an explicit state machine (claimed, implementing, validating, validation-failed/repair-lane, validated, committing, evidence-recording, closing, terminal-disposition): every convergence guardrail is an edge guard on a named transition, block messages must name the blocked transition and exact permitted next action, and the dispatch overlay owns continuation, post-failure handoff, and graceful-stop draining edges. | convergence-state-machine.md | Convergence |
| AD-287 | `internal/tools/policy.go` is decomposed by ordered same-package file extraction into domain files (browser first, validation last) with test splits in the same commits, per-file MarsDocSync blocks, checkpoint tool-policy replays, and a hard boundary against mixing extraction moves with AD-286 state-machine behavior changes. | policy-decomposition.md | Architecture |
| AD-288 | Context budgeting clamps to the actually served inference window: token estimation is calibrated conservative (~3 chars/token, demo-12 wedge as regression floor), the executor budgets the agent loop from the router's per-tier served context length, and server-side `exceed_context_size` rejections become a typed error that clamps the window and prunes-and-retries instead of failing the job. | context-efficiency.md | Context |
| AD-289 | Runtime convergence failures (`max_turns`, `circle_detected`) get one automatic same-role `convergence_retry` per failure fingerprint (`repo:role:category`) through the AD-286 `operator-retry-routing` dispatch-overlay transition; exhausted budgets escalate with a recorded `blocked/operator_retry` disposition naming the exact retry command, while environment failures keep the AD-135 halt. | delivery-operating-model.md | Convergence |
| AD-291 | Foundation-owned runtime changes must be validated by running the installed `mars` binary against a clean validation project with matching git/DB bootstrap intent, recorded AD-285 evidence, and AD-284 minimum archetypes; unit tests alone do not confirm lifecycle fixes. | foundation-operating-model.md | Foundation |
| AD-292 | Foundation stabilization follows the AD-138 improvement loop with explicit stop rules for wedged replays, batched post-change replays, and `make install` before replay. | foundation-operating-model.md | Foundation |
| AD-293 | Ephemeral external runtimes are allowed for optional validation lanes only when they are explicitly selected, job-scoped, managed through first-class tools or `dependency_sync`, write artifacts to ignored/target-owned/temp paths, prove cleanup with postflight hygiene and `git_status`, and keep runtime/setup/cleanup failures out of target backlog unless target-owned. | ephemeral-validation-runtimes.md | Validation |
| AD-294 | Compartmentalised Agent Smoke is a source-only fast validation lane that generates fresh ephemeral role-stage targets through foundation tools, cycles API/web/game/CLI/library/docs/maintenance shapes, records failure classes and would-be dispatch, and complements rather than replaces AD-284 clean-project lifecycle sweeps. | foundation-operating-model.md | Validation |
| AD-295 | Agent Smoke executes selected roles live through the server job path, in parallel where requested, against isolated ephemeral targets and suppresses follow-on dispatch while recording the would-be next role. | agent-smoke-validation.md | Validation |
| AD-296 | Fake, stub, mock, canned, or scripted LLM endpoints are test-only plumbing for agent-smoke and must never be counted as live validation evidence or role-behavior success. | agent-smoke-validation.md | Validation |
| AD-297 | `mars start` classifies existing lifecycle state before seeding CEO, requires `--new-lifecycle` for intentional reseed, preserves review rework pins through Orchestrator, and blocks planner commits of product implementation paths. | delivery-operating-model.md | Lifecycle |
| AD-298 | Foundation plans created from live validation, telemetry, operator feedback, subagent notes, or source investigations must use a confidence-gated template with evidence classification, an assumption confidence matrix, explicit validation requirements, and completion evidence that revisits those assumptions. | foundation-operating-model.md | Foundation |
| AD-299 | Full lifecycle `mars start` can use a real OpenAI-compatible `--model-endpoint` override, scoped start cleanup avoids killing peer runs, occupied default control-plane ports fall back to ephemeral local listeners, and local inference uses bounded tier-port reservations with terminal `inference_port_conflict` errors instead of bind/restart loops. | local-inference.md | Inference |
| AD-300 | Foundation plans and validation reports must lead with a Primary Outcome Contract, use `primary_passed`, `primary_failed`, `primary_blocked`, or `supporting_only`, and cannot frame supporting evidence as primary completion when the primary pass gate is unmet. | foundation-operating-model.md | Foundation |
| AD-301 | Static browser lifecycle completion requires same-session served-page smoke on an application port; reserved MARS ports and canned console-output smoke cannot satisfy ticket evidence, review approval, or live validation claims. | delivery-operating-model.md | Validation |
| AD-302 | Board-driven integrations are optional profile gates: missing or unknown config keeps the CEO-led strict-trunk flow, generated targets get an example config only, board-driven suppresses only planning cron schedules, warm restart replaces stale schedules, and future tools are injected only after profile, section, and registry checks pass. | board-driven-integrations.md | Integrations |
| AD-303 | JIRA mirroring is pull-only and scope-gated: no direct LLM jobs per JIRA event, provider-selected REST or job-scoped Atlassian MCP reads, config-owned project/workspace/label/board containment before ticket writes, and idempotent local ticket reconcile by `jira_key`. | board-driven-integrations.md | Integrations |
| AD-304 | External AI coding clients use role-assuming subagents or role-labelled work packets for non-trivial foundation source work while the primary client remains accountable as `foundation-maintainer` and Orchestrator. | foundation-operating-model.md | Foundation |
| AD-305 | Weak first-slice proof remains pre-proof but recoverable: CTO rejects verification-only first-slice tickets and may re-ticket the exact first executable scenario when weak done evidence already claimed it. | delivery-operating-model.md | Lifecycle |
| AD-306 | Hardware-gated model routing uses one resolver for local bundle eligibility, cloud provider configuration, secret-safe `api_key_env` credentials, and setup/init/runtime CLI output contracts. | local-inference.md | Inference |
| AD-307 | MARS uses cognition-orchestration patterns as a local architecture lens: workflow type, agent pattern, route rationale, scatter-gather aggregation, simulation episodes, evidence-bound evaluator loops, and saga compensation should evolve as source-first local primitives before any generated-target mirroring. | cognition-orchestration-patterns.md | Orchestration |
| AD-308 | External AI coding clients consume the source-only MARS Orchestrator planning model when building the foundation harness: active goal, active exec plan, BDD feature contract, tickets, then implementation evidence. | foundation-operating-model.md | Foundation |
| AD-309 | Control/dashboard listeners are loopback-only, and optional GitHub webhook ingress requires HMAC, trusted numeric actors, exact repository/branch and same-repo provenance, plus bounded in-memory and durable delivery/body replay identity. | github-app-integration.md | Security |
| AD-310 | The embedded dashboard wraps its full mux in one fail-closed browser gateway: direct loopback anonymity is limited to data-free shells, embedded assets, and a minimal path-free status projection; all other reads and every mutation require the documented session/request policy, remote proxy reads require auth, and pinned browser assets run offline under a strict CSP. | dashboard.md | Security |
| AD-312 | Bespoke implementation superseded by AD-313/T-065; exact post-upload convergence remains a future F-018-S004 cutover invariant. | release-versioning.md | Release |
| AD-313 | Historical private snapshots used pinned, publication-disabled GoReleaser/Syft; AD-315 supersedes that implementation for launch while generated targets still choose their own producer. | release-versioning.md | Release |
| AD-314 | The canonical MARS source module requires exact minimum Go 1.25.13 with release toolchain Go 1.27.0; packaged/default and ordinary target operation do not require an externally installed Go toolchain, and generated targets choose their own floor. | source-quality-gates.md | Quality gates |
| AD-315 | The initial public launch uses conventional Go cross-build/archive/checksum production, upstream Syft SBOMs, and GitHub `actions/attest` with split least privilege; the bespoke T-078 security platform is preserved but deferred. | release-versioning.md | Release |
| AD-099 | Generated release notes must include complete user-facing `Impact`, `Why`, and `What Changed` narrative before semantic commit buckets, with topic-aware fallback prose for structural delivery changes. | release-versioning.md | Release |
| AD-100 | Historical marker-backed release notes are backfilled through `mars release backfill-notes`, preserving release buckets while updating narrative sections from commit ranges. | release-versioning.md | Release |