Architectural integrity in the agentic delivery model — what enforces our standards, and where does the Solution Architect fit?

[don-petry]

Status — decisions recorded 2026-07-22 (maintainer):

• Proposals A–E are accepted in principle. This thread is now scoped to how, not whether.

• Blocking Q1 & Q2 resolved: architecture designs live in the repo(s) they describe. Distributed and co-located with the code — not centralised in .github/.github-private, and not exempt for org-infra: every repo that ships something gets its own design, including .github and .github-private. This makes the design a reviewable artifact that travels with the code, versions with it, and shows up in the same PR that changes it.

• Added 2026-07-22 (maintainer): Phase F — continuous refactor. A standing workflow that examines the codebase against the architecture standard, identifies suboptimal areas, and raises refactor PRs. See §5F — this is a different class of mechanism from A–E and changes the shape of the initiative.

• Q0 resolved (maintainer): path is docs/architecture/ — industry-standard, discoverable, ADR-friendly. BMAD's bmad-create-architecture output is redirected to land there instead of _bmad-output/planning-artifacts/; the three existing March-2026 artifacts (TalkTerm / markets / broodly) migrate in (git-mv, history preserved). Phase A amends the org AGENTS.md BMAD path mandate accordingly.

• Decision model — three kinds of content, three authority rules (maintainer):

  • Architecture decisions (ADRs) are idempotent and append-only. Once accepted, an ADR is never rewritten. A changed mind is a new ADR that supersedes the old one; the superseded record stays as history. No agent — and no human — edits an accepted decision in place. This is the normative layer Phases D and F measure intent against.
  • Contract specs are authoritative and mutable — but change is gated and must propagate. A specs/ tree holds the authoritative contracts implementation must satisfy: a DDD domain DSL, OpenAPI, event/message contracts, DDL, and the like. Specs may change (unlike an accepted ADR), but a change is a contract change — it runs the existing Breaking-Changes human-approval protocol, and a bidirectional CI gate proves spec and implementation still agree at the end of every PR. Added 2026-07-23; see Phase G in §5.
  • Current-state views (diagrams, module maps, dependency graphs, descriptions) are regenerable — but the strong preference is deterministic script generation, not LLM interpretation. Derive them from the code by parsing it (imports, module boundaries, call graphs), the same pure-logic + bats discipline as spec-drift.sh / fleet_stub_drift.sh — not from a prompt asking a model to describe the codebase. See the Phase B correction in §5.

  The trichotomy is clean: ADRs say why, specs say what the contract is, views show what the code currently is. ADRs are frozen-once-accepted, specs are gated-mutable, views are freely regenerated.

• All open questions now resolved (2026-07-23). Q3–Q13 decided in a maintainer walkthrough; see the Decisions log (§8). Headlines: architecture review is a separate advisory agent (the solution-architect persona, merging Phases D+E), not a cascade lens; rollout is repo-local-first; SA is advisory-only, dev-lead writes; Phase F is a shared reconciliation engine with 💡 Fleet-Wide Stub Drift Auto-Remediation via Automated PRs #1043, issues-only/human-gated; specs/ is top-level, the DDD contract is a purpose-built DSL (its own epic, broodly first), and conformance checks block from day one once their bats suite is green. This thread is ready to promote to a tracked initiative.

The problem

We have an agentic delivery model that is very good at making changes correct, safe, and consistent, and has no mechanism at all for keeping them structurally sound. Every gate we own asks "is this change right?" — none asks "is the shape of the system after this change still right?"

That asymmetry has a name in the wild: enshittification. In a codebase it looks like this — every individual PR is defensible, every CI check is green, every review is approved, and eighteen months later nobody can change anything without touching nine files. Nothing ever failed. The system just quietly got worse, one locally-optimal merge at a time.

We are running ~223 PRs/month through this pipeline in .github-private alone, most of it agent-authored. If there is a structural ratchet in our loop, it is turning fast.

And gates alone cannot fix this. Every mechanism in A–E below is an inbound gate — it judges a change on its way in. A perfect set of inbound gates gets you exactly one thing: entropy stops increasing. Every structural compromise already merged stays merged, forever, because nothing in the system is ever tasked with going back for it. Holding the line at today's quality is not the goal — today's quality is the thing we're complaining about. That is why Phase F (continuous refactor) is not an optional extra at the end of this list; it is the only proposal here that pays debt down rather than capping its rate of growth.

1. What we have defined

Real, and better than most orgs have:

• Org AGENTS.md carries ~160 lines of architectural doctrine — SOLID, CLEAN, DRY ("three instances before you extract"), DDD (bounded contexts, aggregate roots, repository pattern), KISS, YAGNI, Separation of Concerns (layered architecture, dependencies point inward, no framework bleed), Breaking Changes (a full protocol with a per-layer table and 9 agentic directives), and Code Organization.
• BMAD is mandated — AGENTS.md §"BMAD Method — Spec-Driven Development" requires every repo to produce planning artifacts in _bmad-output/planning-artifacts/, explicitly including an Architecture doc ("technical decisions, component design, data model"), and to run bmad-check-implementation-readiness before a sprint.
• .github-private/AGENTS.md documents ~310 lines of repo-local structural rules — the thin-caller/reusable tier, the channel-tag release model, the rubric-registry contract ("add a manifest row; do not fork the reviewer").

What's missing from the definitions

Gap	Detail
No architecture standard	standards/ has 11 documents — CI, agents, CODEOWNERS, Copilot instructions, Dependabot, push protection, advanced security, GitHub settings, initiatives, personas, ruleset remediation. None of them is about architecture. The doctrine is scattered through org AGENTS.md prose with no stable section ids, so nothing can cite it — and a rule nothing can cite is a rule nothing can enforce.
No decision record convention	We have no ADR practice. There is no place to write down "we chose X over Y and here's the constraint that made it so." So every agent re-derives intent from the code — and code only ever tells you what is, never what was intended.
Principles without thresholds	"Do not add layers of abstraction until complexity demands it" is unfalsifiable as written. No module-size, fan-in/fan-out, dependency-direction, or duplication threshold exists anywhere that a check could evaluate.
No target-state artifact for org-infra	The BMAD architecture artifact is mandated for "every repo," but the two highest-throughput repos in the fleet — .github and .github-private — have no _bmad-output/ at all. Nothing in scripts/, .github/workflows/, or prompts/ references _bmad-output or planning-artifacts anywhere.

2. What actually enforces them — the honest matrix

Gate	What it enforces	Architecture?
lint.yml (shellcheck, markdownlint, actionlint, gh-aw-compile)	syntax, style	✗
validate-workflow-schedules, validate-caller-inputs, template-drift	our own repo-local invariants	✗ (structural for workflows, not for code)
test-deletion-guard, holdout-guard	anti-regression, eval integrity	✗
CodeQL	security vulns / anti-patterns	✗
SonarCloud	maintainability, duplication, hotspots	partial — file-local metrics only; sonar.sources=. on a shell/YAML repo sees almost nothing, and .github/workflows/** is excluded
CodeRabbit	logic, best practice	incidental, unowned
pr-review cascade	risk classification → approve/escalate	✗ — see below
initiative-planner + plan rubric	plan quality	✗ — see below

The review council has no architecture lens

scripts/lib/review-registry.tsv registers exactly four deep specialists: deep_specialist:security, :logic, :performance, :style. Architecture is not one of them, and Tier-1 triage can only emit one of those four type labels — so there is no route to a structural review even in principle.

The closest thing we have is the style lens, and it is explicitly instructed away from this job:

"Keep findings proportional: most style issues are info or minor. Do not block a correct, consistent change over subjective preference — approve it."

That is the right instruction for a style lens. It means the only reviewer positioned to notice structural drift is told to treat it as taste and wave it through.

Worse — the shared risk taxonomy actively auto-approves the erosion. prompts/shared.md classifies:

MEDIUM (auto-approve allowed if all gates pass): … Refactors crossing module boundaries.

A change that crosses a module boundary is precisely the change class that alters system shape. We have it on the auto-approve path. Meanwhile the HIGH taxonomy does contain "The PR explicitly violates org/project standards (…AGENTS.md…)" — but no lens is tasked with checking AGENTS.md §Coding Standards, no lens is given its principles, and no eval case tests for it. It is an unowned line in a shared list.

The planner has no architecture checkpoint — and this is the ratchet

The plan rubric (single source of truth in prompts/bmad/scrum-master.md, adversarially re-applied by prompts/plan-review.md) is six checks: contested_ac, success_metric, cost_cap, untracked_prereq, reviewability, eval_safeguards. All six are about plan hygiene. None asks whether the plan is architecturally sound, whether it respects a boundary, whether three stories are about to introduce three parallel implementations of the same concept, or whether the right move is to refactor first and feature second.

Bob's story template requires Dev Notes to carry "the architecture constraints, the source-tree components to touch, and the testing standards." But look at where he gets them — prompts/bmad/scrum-master.md Step 3:

"Ground every story in the actual repo (Read/Grep/Glob on AGENTS.md, CLAUDE.md, scripts/, .github/workflows/, docs/initiatives/)."

He reads the code. There is no architecture artifact in the loop, so the "architecture constraints" in every story are reverse-engineered from the current implementation. This is the whole problem in one line: the plan can only ever describe and ratify the structure that already exists. A drifted codebase teaches the planner its drift, the planner writes the drift into Dev Notes as a constraint, dev-lead faithfully implements to it, and the drift is now doctrine. Nothing in the loop can ever propose that the current shape is wrong. That is a ratchet, and it only turns one way.

dev-lead can't catch it either

prompts/dev-lead/fix-issue.md Phase 1 does read AGENTS.md — and then produces "a numbered implementation checklist covering every file to create or modify." It's a file plan, not a design plan. Phase 3 says "Do not implement more than what the issue requests," which is correct YAGNI discipline and simultaneously guarantees dev-lead will never fix a structural problem it notices. Phase 5's rubber-duck is a correctness review. The agent is behaving exactly as instructed; the instructions have no design step.

And nothing detects the drift after the fact

scripts/spec-drift.sh (#1144) is the closest existing machinery — but it compares a merged diff against a story's acceptance criteria, it is scoped one-way (spec → code) by design, and it is not wired into any workflow yet (only bats tests reference it). Note also that the Kiro reconciliation (docs/initiatives/kiro-gap-analysis.md) marked "spec-driven planning" as already-covered on the strength of the story DAG — which is true for task decomposition and silently untrue for architecture. Its one carried sub-gap, G1, was scoped to AC-drift only.

3. The evidence that this is already happening

The three product repos that did run BMAD properly:

Repo	_bmad-output/planning-artifacts/architecture.md last touched	Repo last pushed
TalkTerm	2026-03-24	2026-07-22
markets	2026-03-28	2026-07-23
broodly	2026-03-21	2026-07-22

Four months of continuous delivery against an architecture document that has not been opened since March. .github and .github-private — the highest-volume repos in the fleet — never had one. google-app-scripts has a PRD and no architecture. ContentTwin and bmad-bgreat-suite have neither.

These artifacts were produced by a human running BMAD interactively, once, and then the agentic pipeline was built around them without ever connecting to them. They are not stale because anyone neglected them — they are stale because nothing in our automation has ever had a reason to read or write one.

4. Where Winston fits

BMAD's Solution Architect is already vendored and completely unused. Sitting in frameworks/bmad-method/src/bmm-skills/3-solutioning/:

• bmad-agent-architect — the persona ("favoring boring technology, developer productivity, and trade-offs over verdicts")
• bmad-create-architecture — 8-step workflow with an architecture-decision template
• bmad-check-implementation-readiness — 6-step gate incl. epic-coverage validation and epic-quality review
• bmad-generate-project-context, bmad-create-epics-and-stories

Our persona roster (personas/) has eight roles — business-analyst, dev-lead, devops-lead, pr-review, qa-lead, scrum-master, security-lead, sre-lead, all status: draft. There is no architect. We staffed the whole delivery org and left out the one role whose entire job is the thing we have no gate for.

The adoption path is already paved: qa-lead is the worked example in standards/persona-standards.md for exactly this shape — wrap a vendored framework agent, advisory everywhere, write nowhere. Per persona-standards §1.6 (role, not person) the persona is solution-architect; Winston is upstream's cast name and stays upstream, referenced only as framework.skill: bmad-agent-architect.

Note the precedent worth copying and the one worth avoiding: Bob already consults the Test Architect at plan time (scrum-master.md Step 4) — that's the integration pattern. But qa-lead has sat at draft without a reusable; a persona that only exists as a manifest changes nothing.

5. Proposal — seven phases, cheapest first

A–E are sequenced so each is useful alone and none depends on a later one. F (continuous refactor) depends on B and D — it is unsafe without a design to measure against and a lens to judge its output. G (contract conformance) depends on A (which defines the specs/ location and the conformance contract) and is otherwise independent — a repo can adopt G per spec type without any of C–F.

A. standards/architecture-standards.md (org repo). Lift the scattered doctrine out of AGENTS.md prose into one citable standard with stable ids, and define the ADR convention — docs/architecture/adr/NNNN-title.md, sequential, status field (proposed/accepted/superseded-by), immutable once accepted (a reversal is a new ADR, never an edit — the idempotency rule). Give the unfalsifiable principles a testable form (dependency direction, declared module boundaries, the DRY rule-of-three as a reviewable claim). Amend the org AGENTS.md BMAD section to point architecture output at docs/architecture/ (Q0). Also define the specs/ location and the contract-conformance rules (the authoritative-contract layer G enforces): the recognised spec types (DDD DSL, OpenAPI, event/message contracts, DDL, …), where each lives, and the invariant that implementation must satisfy its spec at all times. Nothing can enforce a standard it cannot cite — this unblocks C, D, F, and G.

B. A live architecture artifact — in every repo, at docs/architecture/, split by authority (corrected). My original proposal here was wrong and I'm flagging it as a defect: I said refresh the artifact on the readme-refresh.yml mechanism — regenerate from live state, open a rolling PR. That's correct for READMEs, which are supposed to describe current state. It is wrong for architecture, because a doc the automation rewrites to match the code can only ever describe what the code already is — drift becomes undetectable, because drift just becomes the new document. That silently defeats D and F. The maintainer's decision model fixes this by splitting the artifact:

• docs/architecture/adr/ — normative, hand-authored, idempotent. solution-architect (Winston, via bmad-create-architecture) facilitates the initial draft and major revisions with a human; the result is committed as source and reviewed in a PR like any code. Automation never rewrites it. This is the intent-of-record that D reviews against and F measures decay against. Winston is an authoring aid at decision time, not a scheduled regenerator.
• docs/architecture/views/ — descriptive, regenerated, deterministic. Diagrams, module maps, dependency-direction graphs, boundary listings — derived from the code by parsing it, not prompting about it (maintainer preference). A pure script walks imports/modules and emits the current-state view + a machine-readable graph; a workflow opens a rolling PR when it changes (the readme-refresh delivery pattern is fine here — it's the LLM-regeneration of the normative doc that was the mistake). This reuses the repo's established "pure logic + bats, LLM only where it must be" discipline (spec-drift.sh, fleet_stub_drift.sh), and the machine-readable graph it emits is exactly the input D and F need — so drift detection becomes a deterministic diff (declared boundaries in an ADR vs. derived graph), with the LLM reserved for explaining a violation, not finding it.

Because the design lives beside the code, two properties follow and are worth designing for: a system change and its ADR/view update can arrive in the same PR (so the D lens compares them), and everything is branch-versioned — no central doc drifting against N repos. .github / .github-private need a view shape that fits a shell + reusable-workflow repo (stub/reusable tiering, channel-tag releases, rubric-registry, prompt-library layering) — most of it already written in AGENTS.md, to be lifted into ADRs rather than invented, with the deterministic view derived from the workflow call-graph.

C. Plan-time gate — architecture in the rubric. Two tiers:

• Cheap, now: add architectural checkpoints to the existing plan rubric (e.g. arch_conformance, boundary_impact). The rubric is already a single-source-of-truth consumed by both Bob's self-check and the adversarial plan-review.md critic — this is additive to an existing gate, not a new one.
• For initiatives above a size threshold: a real solutioning stage between idea-triage and Bob, where solution-architect emits or updates the architecture artifact and Bob decomposes against that artifact instead of against the current code. This is the phase that breaks the ratchet — it's the only proposal here that lets the pipeline conclude the existing shape is wrong.

D. Review-time — a separate architecture-review agent (Q3 decided), split blocking-vs-advisory. Decision: not a fifth lens inside the pr-review cascade, but its own reviewer — the solution-architect persona acting as an advisory architecture reviewer, the way qa-lead is a separate advisory test reviewer. This is cleaner than bolting a lens onto a cascade whose risk model is oriented around merge-safety (approve/escalate), not structural quality — and it merges D with E (the persona is the reviewer; see below). The choice forces a useful split in what actually blocks a merge:

• Block on what you can compute. Objective, machine-checkable violations — Phase G contract conformance, dependency-direction inversions, and boundary violations the Phase B graph can diff against an accepted ADR — are required CI checks. Low false-positive, safe to block, no persona in the loop.
• Advise on what needs judgment. Subjective structural findings — "this is becoming a god-object," "this abstraction is premature (no third instance)," "this concept is now implemented three ways" — are the separate advisory agent's job. It comments, doesn't block, and feeds humans, dev-lead, and Phase F. Fed the computed graph diff as pre-fed context (like triage/downstream-impact today), so the model judges flagged structure rather than hunting for it.

This maps exactly onto the determinism preference: block on the computable, advise on the judgment call. One consequence to make conscious, not accidental: with solution-architect advisory (Q5) and architecture review as a separate advisory agent, the subjective structural layer has no merge-blocking teeth at PR time — it relies on the computable checks above plus humans acting on comments. That is the right advisory-first posture (and matches Q12's staged rollout), but it means the one edit that still has to happen inside the main cascade is real: reclassify "refactors crossing module boundaries" out of auto-approvable MEDIUM in prompts/shared.md, so the cascade stops rubber-stamping structural changes and escalates them for the human + advisory-agent read. That one-line change may be the single highest-leverage edit in this whole proposal.

E. Promote the persona — which, given Q3, IS Phase D's reviewer. D and E are one workstream: personas/solution-architect/persona.yml wrapping bmad-agent-architect, default_mode: advisory, opt_out_label: solution-architect:hands-off, its own advisory review workflow (caller stub + reusable + release channel, per persona-standards §6 — this is the "more infrastructure than one registry row" cost of the separate-agent choice, paid once), evals/solution-architect/{dev,holdout}/, then canary-rings.json and next → ring0 → ring1 → stable behind the eval gate. Advisory-everywhere first — architecture opinions land as comments before they ever land as blocks. The same persona also plays the authoring role in Phase B (ADRs) and the solutioning role in Phase C; the review agent here is its third surface.

F. Continuous refactor — the entropy pump. A standing workflow that periodically examines each repo against its own architecture design (Phase B) and the architecture standard (Phase A), identifies the highest-value structural decay, and raises a refactor PR to fix it. Detect → remediate → verify, on a loop, forever.

This is not a new pattern for us — it's an existing one applied one level up. Idea #1043 ("Fleet-Wide Stub Drift Auto-Remediation via Automated PRs") is already idea:approved and proposes exactly this reconciliation loop for stub/config drift against canonical standards, on top of fleet_stub_drift.sh's ALIGNED/DRIFTED/MISSING model. Phase F is the same loop over code structure against architecture standards. The two should almost certainly share machinery and vocabulary rather than being built twice — see Q6.

What it looks for is the Phase D lens pointed at the corpus instead of the diff: dependency-direction inversions, layering violations, a concept implemented a second and third time, abstractions built for two cases that never got a third, framework bleed into domain code, config sprawl, modules that have quietly become god-objects. Detection is deterministic-first, matching the Phase B decision: the same script that derives the current-state graph flags where it violates an accepted ADR's declared boundaries — that's a computed finding, not an LLM opinion. The LLM's job is to rank the computed candidates by value and draft the remediation, not to decide what counts as decay. This keeps F's per-scan token cost bounded (the expensive whole-corpus read is a parse, not a prompt) and makes its findings reproducible and arguable against a named ADR rather than against taste.

Three constraints bind this hard, and two of them are already measured:

1. The PR queue is nearly full. standards/pr-limits.json sets a signed-off org-wide soft ceiling of 50 concurrent open non-draft automation PRs, enforced source-side by scripts/lib/pr-limit-gate.sh. The ADR baseline was ~47 open, ~34 non-Dependabot automation — dev-lead alone holds ~30. A refactor stream does not get to pretend this headroom exists. It must read the cap from that file (never hardcode it), defer rather than fail when at ceiling, and it must not starve dev-lead of queue slots to do cleanup work.
2. Review capacity is one human and a rate-limited bot. Per Evaluate additional AI code-review services (benchmark + rate-limit + cost analysis) #1348 we are a single-seat shop at ~223 PRs/mo with CodeRabbit Free at 1 review/hour. A refactor PR is harder to review than a feature PR — it's large, mechanical, and behavior-preserving-by-claim. Generating them faster than they can be reviewed converts a code-quality problem into a review-queue problem and buys nothing.
3. The DRY rule cuts both ways. Org AGENTS.md says "premature abstraction is worse than duplication — wait until you have at least three concrete instances." A refactor agent that only knows "duplication bad" will spend its entire budget building the exact abstractions the standard forbids. The rule-of-three must be a hard constraint on what it is allowed to propose, not a preference.

Sequencing hazard — F must not ship before D. A refactor PR is, by definition, a "refactor crossing module boundaries" — which prompts/shared.md currently classifies as MEDIUM, auto-approve allowed. Shipping continuous refactor before the architecture lens and that reclassification exist would mass-produce boundary-crossing changes on the auto-approve path with no reviewer competent to judge them. That is not entropy reduction; it is automated entropy with a green check. F depends on D. It also depends on B — without a design artifact to compare against, "suboptimal" collapses into the agent's taste, which is precisely the ratchet in §2 wearing a different hat.

What already protects us and should be kept in the loop rather than re-invented: test-deletion-guard.yml (a refactor PR cannot silently drop a test — it needs an explicit ack-test-deletion label), the Breaking Changes protocol in org AGENTS.md (a refactor touching a public signature needs human approval — behavior-preserving is a claim to be checked, not trusted), and readme-refresh.yml's rolling-PR-never-direct-push discipline.

Start smaller than "raises a PR." The cheapest useful version is a standing report + issues, not PRs: the scan runs, ranks candidates, and files (or refreshes a single rolling issue of) structural-debt candidates that a human promotes into the existing idea:approved → initiative-planner → dev-lead path we already trust. That gets the detection value immediately at near-zero queue cost, proves the finding quality is real before we spend PR slots on it, and reuses the whole pipeline rather than bolting a second PR-producing agent onto a queue that's at 47/50. Graduate to direct PRs per-category, once a category's findings have a track record of being accepted.

G. Contract conformance — specs as the authoritative source, CI as the enforcer. A specs/ tree holds the contracts implementation must satisfy, and a CI gate proves — on every PR — that spec and implementation still agree. This is the layer that turns the Breaking-Changes protocol from prose into an enforced invariant.

The invariant (bidirectional). Spec is authoritative; implementation must conform to it at all times. Four PR shapes, and what CI does with each:

PR shape	Verdict
impl changes, spec unchanged, impl still conforms	✅ pass
impl changes, spec unchanged, impl now violates spec	❌ fail — silent contract drift; this is the "implementation of the specs unchanged by any PR" clause. The effective contract must not move away from the spec.
spec changes, impl not updated to match	❌ fail — a spec change that doesn't propagate leaves the contract unmet. This is the "spec changes must propagate into implementation" clause.
spec and impl change together and conform	✅ pass CI — but this is a contract change: it runs the existing Breaking-Changes human-approval protocol (additive-first, deprecate-then-remove, version/flag), gated by an ack-contract-change label in the test-deletion-guard mould. Green CI ≠ auto-approve for this shape.

That fourth row is the "mutable with strict guardrails" the maintainer asked for: specs can change, but only as a deliberate, human-approved, propagated change — never a silent one.

Deterministic per spec type — matching this turn's determinism decision. Conformance is exactly the kind of thing that should be computed, not LLM-judged; mature tooling exists per type. The standard defines the contract; each repo wires the checker for the spec types it actually uses (opt-in per type, the way ci.yml is customised per stack — a repo with no OpenAPI spec gets no OpenAPI gate):

Spec type	Authoritative form	Deterministic conformance check
OpenAPI	specs/openapi/*.yaml	route/handler introspection vs. spec (schemathesis / dredd-style contract tests); oasdiff-class breaking-change classification on the spec diff itself
Event / message contracts	JSON-Schema / Avro / Protobuf	schema-registry compatibility check (buf breaking, Avro/JSON-Schema compat) — backward-compat is the default gate
DDL / schema	specs/db/*.sql (declarative)	diff declared DDL vs. the schema migrations actually produce (migra / alembic --check-class); fail on undeclared drift
DDD domain DSL	specs/domain/* (a purpose-built DSL — Q11 decided)	codegen-and-verify-clean: generate the expected types/interfaces from the DSL and assert the committed code matches — the exact golden-fixture pattern already in tests/test_downstream_impact_regression.bats, one level up.

The LLM is reserved for explaining a violation in the PR comment, never for finding it — same division of labour as Phases B/D/F. A pure contract-conformance.sh (pure classifiers + bats, main() does I/O) mirrors spec-drift.sh's structure.

Severity — blocking from day one (Q12 decided). Each conformance checker is a required status check the moment it lands for a repo — no advisory soak. This is defensible because the checks are deterministic: a computed conformance check either matches or it doesn't, so the false-positive risk that would make blocking-an-unproven-fuzzy-check dangerous mostly doesn't apply. The residual risk is a checker bug (a wrong checker blocks a good PR), and the mitigation is non-negotiable: a checker earns "required" only after its own bats suite is green — the checker is proven before it gates, not soaked in production. Contracts are treated as sacred; a violation stops the merge.

The purpose-built DSL (Q11) is the one genuinely novel build in this entire proposal. Everything else adapts an existing tool (oasdiff, buf, migra) or an existing pattern (golden-fixture, pre-fed context, rolling-PR delivery). A bespoke DDD DSL needs three new things — a grammar, a generator (DSL → per-stack types), and the codegen-and-verify harness — and it deserves to be its own scoped sub-initiative with a deliberately minimal MVP grammar (aggregates, entities, value objects, identifiers; not the whole DDD tactical catalogue on day one), proven end-to-end on broodly before any second stack. This is the highest-effort, highest-uncertainty line item here; scoping it as a checkbox under G would under-serve it. Flagging it plainly so planning sizes it as the epic it is.

Name collision to avoid. scripts/spec-drift.sh already exists and means something different — it's the LLM-based, initiative-scoped comparison of a merged PR against a story's acceptance criteria (#1144). Phase G is deterministic contract↔implementation conformance. Different inputs, different mechanism — it must not reuse that name or that script. (If anything, it's the deterministic sibling the AC-drift tool's header already gestures at.)

How this lands on existing machinery — mostly by activating what's already written:

• The Breaking-Changes protocol in org AGENTS.md already enumerates the contract surface (§"Shared contracts": "removing/renaming fields in API schemas, changing message payload structures, modifying shared type definitions consumed by multiple services") and demands human approval — but nothing detects it today. G is the missing detector: oasdiff/buf breaking classify the spec change deterministically, and the existing HIGH-risk taxonomy + human gate handle it. The rule exists; G gives it teeth.
• The D lens treats any spec↔impl divergence the CI flags as a HIGH finding, not a style nit.
• Phase F must never touch specs/. Specs are authoritative; a refactor agent may change implementation to conform to a spec, never change a spec to match drifted code. Add specs/ to F's denylist (Q9).

Reality check — the fleet is greenfield here, and that's the argument for doing it now. A sweep of the fleet found no OpenAPI, proto, GraphQL, or DDL anywhere (broodly, the most built-out repo, is a TS monorepo with apps//packages//infra/ but no formal contract tree). So G governs contracts that mostly don't exist yet. That is precisely when to set the standard — defining specs/ and the conformance gate before contracts proliferate ungoverned is cheap; retrofitting conformance onto a fleet full of implicit, undocumented contracts is the expensive path we're trying to avoid. Practically: ship A's top-level specs/ definition + the conformance-gate framework now; each checker becomes a required gate per repo as that contract type appears (blocking on arrival, Q12). broodly is the first adopter — real TS domain types, and the proving ground for the purpose-built DSL (Q11).

6. Success metrics

• Artifact freshness: max age of architecture.md across active repos < 30 days (today: ~120 and climbing).
• Detection: architecture findings raised pre-merge vs. structural problems found post-merge (baseline via a one-off audit of the last ~200 merged PRs before the lens ships).
• Ratchet broken: ≥1 initiative per quarter where the plan proposes a structural correction rather than only conforming to existing structure — the direct counter-metric for enshittification.
• No throughput regression: dev-lead cycle time and PR-to-merge latency within +10% of baseline; the architecture lens must not become a queue.
• Debt paid down, not just capped (Phase F): net structural findings closed per month > net findings opened. If this ratio is ≤1 the entropy pump isn't pumping, and F is failing at its only job regardless of how many PRs it produced.
• F earns its queue slots: acceptance rate of refactor candidates (merged, or promoted to an issue a human actually planned) ≥ 60%. Below that it is generating review load, not value — and the honest response is to narrow its categories, not to raise the cap.
• F respects the ceiling: zero instances of the refactor stream pushing the automation queue over the pr-limits.json cap, and no measurable reduction in dev-lead's available queue slots.
• Contract conformance holds (Phase G): zero merged PRs that leave specs/ and implementation in disagreement (the gate is a required check, so the target is structural, not aspirational). And every contract change that merges carries the ack-contract-change label + a human approval — no silent contract mutations.
• G is deterministic: ≥95% of conformance verdicts are produced by the computed checker with no LLM call; the LLM budget for G is spent only on explaining the minority that fail. If that ratio drops, G has become a prompt where it should be a parser.

7. Cost cap

• Architecture lens routes only on PRs classified MEDIUM or higher and touching >1 module/boundary — not every PR. Docs, lockfiles, and single-file changes never invoke it.
• Artifact refresh: weekly max, per repo, on the readme-refresh cadence and mechanism.
• Solutioning stage: initiatives above an explicit size threshold only (to be set in planning), never per-story.
• Explicit monthly token ceiling set at plan time and tracked in the Token Cost Observatory alongside the other agents.

Phase F specifically — a whole-corpus scan is the most expensive thing proposed here, and the one most able to run away:

• Scan cadence: weekly per repo, max. Incremental where possible (scan what changed since the last pass plus a rotating slice of the corpus) rather than re-reading everything every time.
• Output cap: a hard ceiling of N candidates per repo per week (N small — start at 1–3), enforced in code, and log()-visible when it truncates. Per this repo's own "no silent caps" rule, a scan that found 40 things and reported 3 must say so — a silently truncated list reads as "the codebase is nearly clean," which is the exact opposite of the truth and the most dangerous possible failure mode for this agent.
• Queue discipline: reads automation_open_pr_cap from standards/pr-limits.json, defers when at ceiling, never counts itself exempt.
• Token ceiling: its own line item in the Token Cost Observatory, separate from the review and dev-lead budgets, so a runaway scan is visible as itself and not amortised into "agents cost more this month."

Phase G is nearly free by design — it's a deterministic CI check (parse + diff), so it adds a required-check job on the existing Lint/CI surface, not a new scheduled LLM workload. Its only LLM cost is drafting the explanation comment on a failing PR, which is bounded by failure count, not corpus size. This is the cheapest enforcement mechanism in the whole proposal and the one with the hardest guarantee.

8. Decisions log

Every open question is now resolved (maintainer, 2026-07-22 / 2026-07-23). Kept as a log so the planner sees not just what was decided but why, and so a reversal is a visible, dated change rather than a silent one.

Artifact model (Q1, Q2, Q0, authority):

1. Where does the design live? → In the repo(s) it describes, co-located with code. Distributed, not centralised.
2. Org-infra included? → Yes, no .github/.github-private exemption. Remaining work is the view shape for a shell+reusable repo, not whether one exists.
3. In-repo path? → docs/architecture/ (adr/ + views/). BMAD output relocates there; the three March-2026 artifacts migrate in (git-mv).
4. Authority model? → Three layers. ADRs — normative, idempotent, never rewritten. Specs — authoritative, gated-mutable (Phase G). Views — regenerated deterministically by script, not LLM prose.

Persona & enforcement (Q3–Q5):

5. Architecture review — lens or agent? (Q3) → A separate architecture-review agent, not a lens in the pr-review cascade — the solution-architect persona as an advisory reviewer (like qa-lead). Merges Phase D into E. Blocking teeth come from computable checks (Phase G + graph-diffable boundary/dependency violations as required CI); the subjective structural read is advisory. See §5D.
6. Org-wide or repo-local first? (Q4) → Repo-local first. Prove the standard, the review agent, and the gates in .github-private, then promote into standards/ via the established pattern. The greenfield fleet gives the runway.
7. Does solution-architect write code? (Q5) → Advisory-only; dev-lead writes. SA identifies debt and authors specs/ADRs; dev-lead implements. Safe persona default (persona-standards §1.3); no new write-capable identity.

Phase F — continuous refactor (Q6–Q9):

8. Share machinery with 💡 Fleet-Wide Stub Drift Auto-Remediation via Automated PRs #1043? (Q6) → Shared engine, pluggable detectors. One detect→remediate→verify core; stub-drift (💡 Fleet-Wide Stub Drift Auto-Remediation via Automated PRs #1043) and structural-drift (F) are detectors. 💡 Fleet-Wide Stub Drift Auto-Remediation via Automated PRs #1043 lands first and must be built detector-agnostic now so F slots in.
9. Issues or PRs? (Q7) → Human-gated; F files issues. Ranked structural-debt issues promoted via idea:approved → planner → dev-lead. No auto-enqueue, no SA PRs. Direct-fix graduation out of scope for v1.
10. Queue budget? (Q8) → Deferred; the PR cap is not a limiting factor for this initiative. Issues-only means near-zero direct queue cost; do not build queue-budget machinery around the cap now.
11. F denylist? (Q9) → Settled. frameworks/ subtrees, agent-shield.yml + immutable set, held-out evals/, thin caller stubs, and specs/. Composes with holdout-guard.sh + AgentShield.

Phase G — contract conformance (Q10–Q13):

12. specs/ location? (Q10) → Top-level specs/. Contracts are machine-consumed (codegen, validation, registry), not human docs — they don't belong under docs/. The standard catalogues it; an ADR records the choice.
13. DDD DSL form? (Q11) → Purpose-built DSL. The one genuinely novel build here (grammar + generator + codegen-and-verify harness). Scoped as its own sub-initiative with a minimal MVP grammar (aggregates, entities, value objects, identifiers), proven on broodly first. Sized as an epic, not a checkbox — see §5G.
14. Enforcement severity? (Q12) → Blocking from day one. Each conformance checker is a required status check on arrival — defensible because the checks are deterministic (no fuzzy false-positive class). The one hard rule: a checker earns "required" only after its own bats suite is green (proven before it gates, not soaked in prod). Contracts are sacred; a violation stops the merge.
15. Shared breaking-change classifier? (Q13) → Implementation detail, resolved at build time. oasdiff/buf breaking should live as a shared lib (à la scripts/lib/downstream-impact.sh) consumable by both G and the review agent, not G-only — a design note for the builder, not a decision needing a call.

---

Grounding: org AGENTS.md §§Coding Standards / BMAD; standards/ (11 docs, no architecture standard); scripts/lib/review-registry.tsv; prompts/shared.md, prompts/deep-review-style.md, prompts/plan-review.md, prompts/bmad/scrum-master.md, prompts/dev-lead/fix-issue.md; scripts/spec-drift.sh; docs/initiatives/kiro-gap-analysis.md §§2/5; frameworks/bmad-method/src/bmm-skills/3-solutioning/; personas/ (8 roles, no architect); standards/persona-standards.md §§1.2/1.3/1.6/7; standards/pr-limits.md + standards/pr-limits.json (cap 50, baseline ~47/~34, dev-lead ~30) + scripts/lib/pr-limit-gate.sh; Discussions #1043 (approved) and #1348; org AGENTS.md §Breaking Changes (“Shared contracts”); scripts/spec-drift.sh (AC-drift, name-collision note); tests/test_downstream_impact_regression.bats (golden-fixture pattern); fleet contract sweep 2026-07-23 (no OpenAPI/proto/GraphQL/DDL found); artifact timestamps read live from the fleet on 2026-07-22.

[don-petry]

Refresh + scoped first cut — 2026-08-31

Read this as an amendment to the body above, not a replacement. The Q0–Q13 decisions stand; nothing here reopens them. But they were recorded on 2026‑07‑22/23. Five weeks on, four of their factual premises have moved, one premise has silently failed, and two hard CI gates that did not exist then now bind any new agentic role. This comment corrects the base, records what changed, and — most importantly — scopes the initiative that idea:approved should plan, which is deliberately not all of A–G.

(Handles below are written without the @ on purpose — naming a live persona handle in a Discussion comment is a way to self-trigger the mention router.)

---

0. Scope for the planner — read this before decomposing

idea:approved on this thread should produce one epic: onboard solution-architect as an addressable advisory persona, give it an architecture-of-record to cite, and promote it past draft. That is Phase E, the advisory half of Phase D, and the minimum viable slice of Phase B — nothing else.

Phases A, C, F, G and the fleet-wide half of B stay in this Discussion for later cuts. Do not create stories for them. Full in/out list in §7.

---

1. Corrections to the factual base

Every row verified live on 2026‑08‑31.

Claim in the body	As written (2026‑07‑23)	Verified now	Consequence
PR queue pressure	"nearly full", ~47 open / ~34 automation, dev-lead ~30	org-wide 27 open non-draft, 23 non-Dependabot; .github-private holds 3, all human-authored, zero dev-lead	§5F's hardest stated constraint is void. Headroom roughly doubled. Q8 ("the PR cap is not a limiting factor") was right, and is now obviously right.
Throughput	"~223 PRs/month … the ratchet is turning fast"	159 merged in July, 74 in August	The ratchet turns at ~⅓ the cited rate. The urgency argument weakens; the structural argument is unchanged. Worth restating honestly rather than leaving an inflated number in the record.
standards/ inventory	"11 documents … none of them is about architecture"	15 markdown standards + 8 machine-readable configs	Phase A's gap holds — still zero about architecture — but the count is stale. New arrivals matter: persona-standards.md + standards/personas/, pr-limits.json (signed-off), agent-rate-limits.json (provisional).
spec-drift.sh	"not wired into any workflow yet (only bats tests reference it)"	Wired. .github/workflows/spec-drift.yml shipped (#1146, epic #1142)	Stale, and usefully so: post-merge, exactly one detector run per merged initiative-story PR, advisory-comment-only, never blocks, gated OFF by default behind SPEC_DRIFT_ENABLED. That is now the proven delivery shape for an advisory drift detector. Phase F should copy it, not invent one.
Artifact freshness	"~120 days and climbing"	broodly 163d, TalkTerm 160d, markets 156d — all three pushed today	§6's baseline restates to 163 days. The metric got worse by exactly the elapsed time, which is the point.
Review council	"exactly four deep specialists"	Still exactly four (security, logic, performance, style); none architectural	Holds.
prompts/shared.md MEDIUM	"Refactors crossing module boundaries" is auto-approvable	Still there, line 77, still auto-approvable	Holds — and remains the single highest-leverage one-line edit in the whole proposal.
Persona roster	"eight roles … all status: draft"	Still eight. Still all eight draft, seven weeks later. canary-rings.json now carries persona-mention (the router) but not one persona	Not just holds — got worse. See §5.

---

2. The premise that silently failed — Q6

Q6 → "Shared engine, pluggable detectors. One detect→remediate→verify core… #1043 lands first and must be built detector-agnostic now so F slots in."

#1043's initiative (#1148) closed 2026‑07‑16 — six days before Q6 was recorded. It did not land as a detector-agnostic engine. scripts/ today holds three unrelated siblings: fleet_stub_drift.sh, template_stub_drift.sh, spec-drift.sh.

So Q6's precondition is not merely unmet — it is unmeetable as written. The thing that was supposed to land first had already landed, differently.

Consequence for Phase F: it must either (a) build the shared engine itself and retrofit the three existing detectors, or (b) accept a fourth sibling and drop the shared-engine claim. That is a real decision Q6 assumed away. Out of scope for this cut — flagged here so it is not discovered at F's planning time.

---

3. Two hard gates that did not exist on 2026‑07‑23

a. The agentic interaction model is now CI-enforced (#1402, delivered 2026‑08‑01/02)

docs/agentic-interaction-model.md is normative and repo-local. scripts/validate-interaction-model.sh runs in lint.yml, and its first violation class reads:

FAIL[a] — an in-scope workflow has no §4 classification row (or a duplicate row). Adding a new agentic role without declaring it fails here.

Every role now carries a machine-readable contract (personas/<id>/interaction.yml, interaction-contracts/<name>.yml) declaring trigger events, timers, emits, idempotency key, concurrency lane, stop markers, and budget.

Consequence for Phase E: solution-architect ships its interaction.yml in its first PR, or CI fails. qa-lead's had to be backfilled three weeks after its manifest (#1404). Winston does not repeat that.

Second consequence, worth stating plainly — qa-lead's contract says so in its own header: the contract records what is deployed, not what is aspired to. So the manifest's declared surfaces must be trimmed to what the router actually wires. qa-lead declares seven surfaces; five of them dispatch nothing (persona-standards finding 10 / combsmith/.github#755).

b. Script-only changes never reach the fleet (#1592, OPEN)

Autocut cuts a new channel version when a reusable's blob changes. All agent behaviour lives in scripts/ and prompts/, checked out at the pinned agent_ref. A change touching only those merges, closes its issue, advances the epic scoreboard — and propagates to nobody. Five merged fixes are in exactly that state right now.

Consequence for the promotion story: solution-architect's advisory logic is a prompt file. Cutting a version and advancing rings will move nothing to consumers until #1592 is fixed. The promotion story must depend on #1592 or route via the persona-mention channel the shared router already owns — and must verify the promotion actually reached a consumer rather than trusting the ring label. Call this out at planning time; do not discover it during the soak.

---

4. Phase E got materially cheaper — the cost objection is already paid

§5E priced the separate-agent choice as "more infrastructure than one registry row (caller stub + reusable + release channel, per persona-standards §6) — this is the cost… paid once."

That bill has already been paid, by someone else. Since this thread was written the persona runtime shipped, and it is convention-driven: one shared router (persona-mention.yml — one stub for every persona) plus persona-runner-reusable.yml serve any persona that drops a manifest and prompts/<role>/advisory.md. No per-persona workflow, no per-persona stub, no new reusable, no new release channel.

The cost curve across the three personas onboarded on that path is the evidence:

PR	Persona	Lines added	Files	Commits	Review rounds
#1174	qa-lead (Murat) — first of its kind	560	7	8	10
#1313	sre-lead	305	5	2	9
#1315	security-lead	321	5	1	2

Three onboardings, and the third cost one commit and two review rounds.

This is the strongest argument yet for Q3's separate-agent choice: the thing that made it expensive stopped being expensive. A dedicated stub/reusable/channel is now needed only if solution-architect ever wants a trigger the shared router does not serve — which this cut deliberately does not.

One more free win: no vendoring story is required. bmad-agent-architect is already vendored at frameworks/bmad-method/src/bmm-skills/3-solutioning/, pinned v6.8.0. #1304 needed a P1 vendoring story costing 19,552 lines and blocking everything behind it. This epic starts with that already done.

---

5. The failure mode this initiative must not repeat

Eight personas. All draft. Seven weeks. Every one shipped with promotion deliberately deferred, and each deferral was locally correct:

• Agentic Persona Framework #1175 non-goals — "Not in this cut: wiring Murat to a dedicated advisory workflow (stays draft)… expanding Murat's held-out eval set to the min_cases gate."
• Epic: Onboard the bmad-bgreat-suite ops personas (sre-lead, devops-lead, security-lead) #1304 finding 8 — "Promotion is out of scope. All three ship draft with seed evals. Real held-out evals + soak + canary registration are a separate, later epic."
• Epic: Persona framework — post-rollout hardening & follow-ups #1318, still open — "Real (non-seed) held-out evals for each persona before any promotion past draft" and "Scored eval-gate harness — only the held-out count is enforced today."

The aggregate of eight locally-correct deferrals is eight manifests and zero promoted personas — precisely what §4 of the body warns about ("a persona that only exists as a manifest changes nothing"), now at 8×.

And the gate that does exist is weaker than it looks: qa-lead's held-out set is 6 synthetic placeholder cases. It clears a count. There is no scorer wired, so nothing has ever measured whether qa-lead's advice is any good.

Therefore: promotion is a story inside this epic, not a follow-up after it. If solution-architect cannot clear a real, scored eval gate, that is a finding worth having — it is not a reason to leave it at draft indefinitely.

---

6. One correction that is architecture-specific, not persona-generic

qa-lead works as a thin wrapper because bmad-tea carries portable doctrine — risk-based test strategy is the same in any repo. Architecture doctrine is not portable.

§2 of the body already names the mechanism exactly: an agent with no architecture-of-record reverse-engineers intent from the code, and "a drifted codebase teaches the planner its drift."

A solution-architect shipped as a bare wrapper over bmad-agent-architect would do precisely that — and would be, structurally, the ratchet wearing a third hat.

Hence the ADR seed is in this cut and it blocks the persona, rather than being deferred to Phase B. Repo-local to .github-private only (Q4: repo-local first), and lifted from doctrine that already exists in AGENTS.md rather than invented. This is the minimum viable normative substrate. The fleet-wide Phase B — views/, deterministic generation, the org standard — stays in this Discussion.

---

7. Scope for idea:approved — the epic to plan

In scope — plan exactly these

S1 — Seed the architecture-of-record for .github-private (no blockers; blocks S2)

• Create docs/architecture/adr/ with 0000-adr-process.md recording the convention itself: sequential NNNN-title.md; status: proposed | accepted | superseded-by-NNNN; immutable once accepted — a reversal is a new ADR, never an edit (the idempotency rule from the decision model above).
• Author 4–6 ADRs by lifting structural doctrine that already exists in AGENTS.md, not inventing new rules. Candidates, all already written down: the thin-caller/reusable two-tier model; the channel-tag release + ring model; the rubric-registry contract ("add a manifest row; do not fork the reviewer", [Phase 1] Define the review artifact contract + rubric registry (pr_diff sole type) #611); the pure-logic-plus-bats discipline (LLM only where it must be); advisory-by-default for personas (persona-standards §1.3).
• Each ADR must state its declared boundary or invariant in a form something could later check — that is what makes Phases B/D/F possible without a rewrite.
• No org standard, no views/, no generation, no other repo. Size: M

S2 — the solution-architect persona (blocked by S1)

• personas/solution-architect/persona.yml — wraps frameworks/bmad-method/src/bmm-skills/3-solutioning/bmad-agent-architect, framework bmad-method pinned v6.8.0 (matching frameworks/bmad-method/VENDOR.md), framework.skill: bmad-agent-architect.
• Role, not person (§1.6): the persona is solution-architect. "Winston" stays upstream, referenced only via framework.skill.
• address.handle: petry-projects/solution-architect.
• Surfaces: only what the router serves — mention, issues, discussion (bridge: repository_dispatch). No pull_request, no check_run, no schedule. (Copy security-lead's trimmed shape, not qa-lead's seven.)
• runtime.identity: { account: don-petry, credential: GH_PAT_DON_PETRY } from birth — dev-lead regressed to committing as donpetry-bot (review-only machine user) instead of don-petry #1316/fix(dev-lead): resolve identity from persona manifest, not shared vars.BOT_USER (#1316) #1317 established that identity resolves from the manifest, and the shared-identity approval friction is what made it matter.
• trust.author_association_floor: [OWNER, MEMBER, COLLABORATOR]; opt_out_label: solution-architect:hands-off.
• personas/solution-architect/interaction.yml — in this same PR (§3a), mirroring the router's deployed on: block.
• prompts/solution-architect/advisory.md — copy qa-lead's contract shape verbatim (sentinel-delimited output, <!-- persona:solution-architect --> as the exact first body line, never emit a literal team handle, every gh call read-only, ≤250 words), specialized to: read the S1 ADRs, and cite by number the ADR it is measuring against. Add one rule that is specific to this role and load-bearing — if it cannot cite an ADR, it says so rather than asserting doctrine. That single rule is what keeps it off the ratchet.
• personas/solution-architect/README.md, including the overlap note (Epic: Onboard the bmad-bgreat-suite ops personas (sre-lead, devops-lead, security-lead) #1304 finding 7): prompts/deep-review-style.md — the one lens positioned to notice structural drift and explicitly instructed to wave it through — plus the pr-review cascade and dev-lead. Advisory persona, not a replacement for any of them.
• Seed evals/solution-architect/{dev,holdout}/cases.jsonl.
• Size: M

S3 — Real held-out evals + a scored gate (blocked by S2)

• Replace the seed cases with ≥5 held-out cases derived from real merged PRs in this repo, de-identified per the evals/ rule. Real boundary-crossing merges exist in the history — that is the corpus, and it is what makes the eval mean something.
• Wire the scored run against evals/judge.md so the gate is scored, not counted. Today only min_cases is enforced (Epic: Persona framework — post-rollout hardening & follow-ups #1318, open since July).
• Stated honestly: the scored harness is shared infrastructure — it unblocks all eight drafted personas, not just this one. If it proves larger than one story it splits into two; it does not get deferred into another follow-up list.
• Size: L

S4 — Promotion past draft (blocked by S3)

• status: draft → next; register agents.solution-architect in canary-rings.json; soak next → ring0 → ring1 → stable, S3's eval gate green before stable (persona-standards §7 DoD).
• Must resolve or route around Script-only changes never reach the fleet: autocut watches the reusable blob, but agents execute scripts/ pinned at agent_ref #1592 (§3b) and verify the promotion actually reached a consumer, rather than trusting that the ring label moved.
• Size: M

S5 — Reclassify boundary-crossing refactors out of auto-approve (blocked by S2)

• prompts/shared.md:77 — move "Refactors crossing module boundaries" out of MEDIUM-auto-approvable so the cascade escalates structural change instead of rubber-stamping it, plus its eval/regression coverage.
• The body calls this "the single highest-leverage edit in this whole proposal." It is one line and it is independent of everything else here.
• Sequenced after S2 deliberately: escalating a structural change is only useful once there is a reviewer to escalate it to.
• Size: S

T — Create the org team (human/session step — not a dev-lead story)
petry-projects/solution-architect, privacy: closed, notification_setting: notifications_disabled, 0 members (remove the auto-added creator). Creating org teams is an org mutation outside dev-lead's PR flow — same treatment as qa-lead's team and #1304's T.

V — Verification gate (not a code change)
Manifest validates (validate-personas.py); validate-interaction-model.sh green; the team resolves as mentionable (gh api /markdown → team-mention), closed, notifications off; and one live smoke test — mention the handle on a throwaway issue and confirm exactly one advisory posts with its marker, that the recursion guard skips it, and that solution-architect:hands-off suppresses it. Mirrors soak #1300.

The DAG

S1 (ADR seed) ──> S2 (persona) ──> S3 (real evals + scored gate) ──> S4 (promotion)
                     │
                     └────────────> S5 (shared.md reclassification)

T (org team)  ── parallel, human/session step
V (verify)    ── gate, after S2 + T

Explicitly out of scope — do not create stories

Remains in this Discussion for later cuts: Phase A (the org architecture standard + the specs/ definition), Phase B's fleet-wide half (views/, deterministic generation, the other repos, the March-2026 artifact migration), Phase C (plan-time rubric checkpoints + the solutioning stage), Phase F (continuous refactor — and its Q6 problem, §2), Phase G (contract conformance and the purpose-built DDD DSL).

Known gaps accepted, not solved

Carried from #1318; do not plan stories for these: discussions have no labels API, so solution-architect:hands-off cannot opt out a discussion; one comment naming N personas fans out to N runs (no quota cap); there is no 👀 acknowledgement reaction, so a summoned persona is silent until it posts.

---

8. Learnings from the Murat trail, applied

Twelve concrete deltas from #1175 → #1174 → #1304 → #1318, and what each changes here:

1. No vendoring phase. bmad-agent-architect is already vendored (§4). Epic: Onboard the bmad-bgreat-suite ops personas (sre-lead, devops-lead, security-lead) #1304 spent a blocking 19,552-line P1 on this; we start past it.
2. Trim declared surfaces to what is served. qa-lead declares seven, five dispatch nothing. Copy security-lead's three.
3. interaction.yml in the first PR, not backfilled three weeks later ([Phase 2] Author a machine-readable interaction contract for every agentic role, per the standard #1404).
4. runtime.identity at birth (dev-lead regressed to committing as donpetry-bot (review-only machine user) instead of don-petry #1316/fix(dev-lead): resolve identity from persona manifest, not shared vars.BOT_USER (#1316) #1317), not retrofitted after an approval deadlock.
5. Promotion inside the epic (§5) — the one change that breaks 8-for-8 draft.
6. Real evals from real merged PRs, and a scored gate, not 6 synthetic placeholders clearing a count.
7. Something normative to cite (§6) — the ADR seed blocks the persona rather than trailing it.
8. Overlap declared in the README (Epic: Onboard the bmad-bgreat-suite ops personas (sre-lead, devops-lead, security-lead) #1304 finding 7) — especially against deep-review-style.md.
9. Copy qa-lead's safety contract verbatim — sentinels, exact marker as first body line, never emit a literal handle, read-only gh only. It is the recursion guard the whole framework rests on.
10. Target the third-onboarding cost, not the first — ~320 lines, 5–6 files, 1 commit, ≤2 review rounds (feat: implement issue #1309 — [bmad-onboard S3] Onboard security-lead persona #1315), not Add Murat persona instance — worked example for the persona standard #1174's 560/7/8/10.
11. Zero standing cost by construction — mention-routed only. No cron, no per-PR fan-out. Explicitly do not wire pull_request: synchronize in this cut; that is exactly what would turn an advisor into a queue (§7 of the body).
12. Verify propagation, don't trust the ring label (Script-only changes never reach the fleet: autocut watches the reusable blob, but agents execute scripts/ pinned at agent_ref #1592, §3b).

---

9. Metrics and cost for this cut

Narrower than §6's initiative-wide set, and each one is measurable on delivery:

• .github-private carries ≥5 accepted ADRs, each stating a checkable boundary or invariant.
• solution-architect reaches stable with a scored eval gate green — the first of eight personas to leave draft.
• ≥1 advisory that cites an ADR by number and is acted on — either the change moves, or a new superseding ADR is written. Both outcomes are successes; the second is the ratchet actually breaking.
• Counter-metric, measured from run one: zero advisories that assert doctrine without an ADR citation. That is the failure mode from §6, and it should be watched rather than assumed away.

Cost. Mention-routed only: a run happens when — and only when — a human types the handle. No cron, no fan-out, no standing token cost. If a per-agent budget is wanted, the right home is now a solution-architect entry in standards/agent-rate-limits.json, which did not exist when §7 was written (it is provisional and inert pending #636 sign-off, so that is a placement decision, not an enforcement one).

---

Ready for idea:approved with §7 as the binding scope.

[github-actions[bot]]

📋 Initiative planned by the BMAD Scrum Master (Bob).

Epic #1627 — Onboard solution-architect as an addressable advisory persona (repo-local first cut)

7 stories created (inert — labelled initiative, NOT initiative:auto):

• [Phase 1] Seed the architecture-of-record (ADR convention + 4–6 lifted ADRs) for .github-private #1628 (M) — [Phase 1] Seed the architecture-of-record (ADR convention + 4–6 lifted ADRs) for .github-private
• [Phase 2] Create the solution-architect advisory persona (manifest + advisory prompt + interaction contract + eval seed) #1629 (M) — [Phase 2] Create the solution-architect advisory persona (manifest + advisory prompt + interaction contract + eval seed)
• [Phase 3] Replace seed evals with real held-out cases and wire a scored (not counted) eval gate #1630 (L) — [Phase 3] Replace seed evals with real held-out cases and wire a scored (not counted) eval gate
• [Phase 4] Promote solution-architect past draft through the release rings, verifying propagation reached a consumer #1631 (M) — [Phase 4] Promote solution-architect past draft through the release rings, verifying propagation reached a consumer
• [Phase 3] Reclassify boundary-crossing refactors out of the auto-approvable MEDIUM tier in prompts/shared.md #1632 (S) — [Phase 3] Reclassify boundary-crossing refactors out of the auto-approvable MEDIUM tier in prompts/shared.md
• [Human] Create the org team petry-projects/solution-architect (closed, notifications off, 0 members) #1633 (S) — [Human] Create the org team petry-projects/solution-architect (closed, notifications off, 0 members)
• [Human] Verification gate: validate manifests, interaction model, team mentionability, and one live mention smoke test #1634 (M) — [Human] Verification gate: validate manifests, interaction model, team mentionability, and one live mention smoke test

---

Review the epic and its sub-issue DAG, adjust as needed, then add initiative:auto to epic #1627 to hand it to initiative-driver for auto-implementation.