Skip to content

[Phase 4] Promote solution-architect past draft through the release rings, verifying propagation reached a consumer #1631

Closed
Closed
[Phase 4] Promote solution-architect past draft through the release rings, verifying propagation reached a consumer#1631
Labels
dev-leadFor dev-lead agent pickupinitiativeEpic / initiative tracking issue

Description

@github-actions
github-actions
bot
opened on Sep 1, 2026

Story

As a maintainer,
I want flip solution-architect from draft through next → ring0 → ring1 → stable behind the green scored eval gate, and confirm the promotion actually reached a consumer,
so that solution-architect becomes the first of eight personas to leave draft, breaking the 8-for-8 stuck-at-draft pattern — and it does so verifiably, not on a ring label alone.

Acceptance Criteria

  1. personas/solution-architect/persona.yml status advances draft → next, and the agents.solution-architect entry is registered in canary-rings.json.
  2. The persona soaks next → ring0 → ring1 → stable, with S3's scored eval gate green as the precondition for stable (persona-standards §7 Definition of Done).
  3. The Script-only changes never reach the fleet: autocut watches the reusable blob, but agents execute scripts/ pinned at agent_ref #1592 propagation hazard is resolved OR explicitly routed around: because solution-architect is mention-routed via the shared persona-mention channel (no dedicated reusable blob), the story documents which path applies and does not silently rely on a ring label moving.
  4. Propagation is VERIFIED against a real consumer — a concrete check that the promoted behavior actually reaches a consumer (e.g. a live mention resolves to the promoted persona), not merely that the ring label advanced.
  5. The promotion does not introduce any new trigger surface (still mention-routed only) — no pull_request: synchronize, no cron, no fan-out added during promotion.

Tasks / Subtasks

Dev Notes

  • This is the story that breaks 8-for-8 draft (§5). Promotion is INSIDE this epic by design — if solution-architect cannot clear the scored gate, that is a finding worth having, not a reason to leave it at draft.
  • The Script-only changes never reach the fleet: autocut watches the reusable blob, but agents execute scripts/ pinned at agent_ref #1592 hazard: autocut cuts a new channel version only when a REUSABLE's blob changes, but all agent behavior lives in scripts//prompts/ checked out at the pinned agent_ref — a prompt-only change can merge, close its issue, advance the scoreboard, and propagate to nobody (five merged fixes are in exactly that state). solution-architect's advisory logic IS a prompt file. Mitigation: because this cut is mention-routed via the shared persona-mention router (which the router already owns and cuts), route via that channel rather than a dedicated reusable — but VERIFY a live mention actually invokes the promoted persona, do not trust the ring label (§3b, learning 12).
  • The canary-rings.json (and optional agent-rate-limits.json) registries live in the org repo petry-projects/.github under standards/, per personas/security-lead/persona.yml's canary.registry pointer — registration is a cross-repo change, coordinated the way other personas register. This is surfaced in the epic's untracked_prerequisites.
  • Definition of Done is persona-standards §7: eval gate green before stable. Mirror the soak shape of qa-lead's [persona-runtime soak] qa-lead mention smoke test #1300 mention smoke test for the consumer-reached verification.
  • Do NOT wire pull_request: synchronize or any cron here — that is exactly what would turn an advisor into a queue (§7 of the body, learning 11). Promotion changes status/rings only, not trigger surface.

Project Structure Notes

Edits personas/solution-architect/persona.yml (status + canary block) and the org-repo standards/canary-rings.json registry (cross-repo). No trigger-surface changes. Verification reuses the mention path served by the shared router.

References

Story prepared by the BMAD Scrum Master (Bob) for epic #1627. Status: ready-for-dev.

Activity

  1. github-actions
    added
    initiativeEpic / initiative tracking issue
    on Sep 1, 2026
  2. github-actions
    added a parent issue on Sep 1, 2026
  3. github-actions
    marked this as blocked on Sep 1, 2026
  4. don-petry
    added
    dev-leadFor dev-lead agent pickup
    on Sep 2, 2026

  5. don-petry commented on Sep 2, 2026

    @don-petry
    don-petry
    on Sep 2, 2026
    Collaborator

    Dev-Lead Implementation Plan

    Issue: #1631 — [Phase 4] Promote solution-architect past draft through the release rings, verifying propagation reached a consumer

    Scope

    Route-around the #1592 propagation hazard for the mention-routed solution-architect, add a re-runnable consumer-reached / no-new-trigger-surface verification, and record the exact sequencing blocker on the draft → next flip — rather than flip the ring label ahead of its registration and ship a hollow green.

    Key finding (surfaced in Phase 1, blocks AC #1/#2 in this repo)

    Implementation Checklist

    Tests to Write

    Test Command

    bats tests/persona_reach_check.bats (full: the bats job list in .github/workflows/lint.yml) plus bash .dev-lead/scripts/dev-lead-lint.sh

    Provisional: nothing is pushed by me; the automation opens the PR and posts the authoritative completion record with PR number + head SHA.

  6. don-petry commented on Sep 2, 2026

    @don-petry
    don-petry
    on Sep 2, 2026
    Collaborator

    Dev-Lead: Progress (in progress — not yet durable)

    Provisional. Nothing is pushed yet; the automation posts the authoritative
    completion record (with PR number + head SHA) after the push. Treat the notes
    below as intent, not delivered results.

    Key scoping decision (intent)

    The draft → next status flip is deliberately not made in this workspace.
    validate-personas fetches the cross-repo petry-projects/.github/standards/canary-rings.json
    and hard-fails any non-draft persona with no agents.<id> entry. That entry does
    not exist on petry-projects/.github@main (checked: the registry lists dev-lead,
    persona-mention, … but not solution-architect) and cannot be authored from this
    repo. Flipping status here alone would turn validate-personas red post-merge — the
    skew / hollow-green class (#1052/#1592) this epic exists to prevent. So this change
    lands the route-around + a re-runnable consumer-reached verification and records the
    exact register-first sequencing, rather than moving a ring label ahead of its
    registration.

    Plan Execution (intended, this workspace)

    Files touched (this workspace, not yet pushed)

    Notes

  7. don-petry commented on Sep 2, 2026

    @don-petry
    don-petry
    on Sep 2, 2026
    Collaborator

    Dev-Lead: Implementation Complete — PR #1664

    The implementation for issue #1631 is durable: commits are pushed and a pull request is open. This record is backed by verifiable artifacts you can confirm in one click.

    Review happens on the PR. Acceptance criteria and test results are evidenced by the PR's diff and CI checks — not asserted here. If a later stage fails, this claim is retracted in place.

  8. don-petry
    added a commit that references this issue on Sep 3, 2026

    feat: implement issue #1631 — [Phase 4] Promote `solution-architect` …

    90dcc01

  9. don-petry commented on Sep 7, 2026

    @don-petry
    don-petry
    on Sep 7, 2026
    Collaborator

    Blocked on a cross-repo prerequisite — combsmith/.github#1078

    Raised combsmith/.github#1078 — Register agents.solution-architect in canary-rings.json (cross-repo prerequisite for .github-private#1631) to unblock AC #1 of this story.

    Why this story has been open since 2026-09-03. PR #1664 merged and delivered AC #3 (propagation posture) and AC #4 (scripts/persona_reach_check.sh + bats). It did not deliver AC #1 (draft → next + registry entry) or AC #2 (the ring soak) — because canary-rings.json lives in petry-projects/.github, and dev-lead cannot reach it from this repo. Verified today: agents.solution-architect is absent from the registry and personas/solution-architect/persona.yml is still status: draft.

    The two halves must land together. The merged reach-check deliberately fails on the skew state — status past draft with no registry entry — so flipping the manifest here before the registry entry exists would turn CI red. That is the design working as intended, not an obstacle.

    A design question surfaced while writing it, and it is worth a maintainer read. All 16 registered agents have a reusable; solution-architect deliberately has none, because it rides the shared persona runtime (persona-mention router → persona-runner-reusable.yml). The ring model watches reusable blobs, so a persona with no blob does not fit the schema cleanly. #1078 carries the recommendation (register against persona-runner-reusable.yml, which is currently unregistered) and names the alternative (personas on a shared runtime inherit the runtime's rings — defensible, but a standards change rather than a config change). It also flags that whichever way this goes sets precedent for the other eight drafted personas.

    Once #1078 merges, the remaining work here is the draft → next flip, the next → ring0 → ring1 → stable soak, and running the scored eval gate — which has never actually been run against this persona, so its score is still unknown.

  10. don-petry commented on Sep 7, 2026

    @don-petry
    don-petry
    on Sep 7, 2026
    Collaborator

    AC #1 and AC #2 are superseded by ADR-0006 — and AC #1 is unimplementable as written

    Maintainer approved Option C in #1688 on 2026-09-07. Two of this story's acceptance criteria no longer describe the intended outcome, and one of them could never have passed. Recording here rather than silently reinterpreting them.

    AC #1 — status advances draft → next, and agents.solution-architect is registered in canary-rings.json

    Both halves change.

    AC #2 — soaks next → ring0 → ring1 → stable

    There is no per-persona channel tag to stage (persona-runner.yml uses a local relative path, no agent_ref). Ring staging for personas is the persona-mention router's, not this persona's. Promotion evidence is scripts/persona_reach_check.sh plus an observed live mention — which #1634 already demonstrated once.

    AC #3, #4, #5 stand unchanged

    They are, if anything, load-bearing now: with rings out of the picture the reach check is the sole automated promotion gate, exactly as ADR-0006's Consequences section states.

    Remaining work on this story

    1. personas/validate-personas.py — drop the non-draft-must-be-registered invariant for shared-runtime personas.
    2. scripts/persona_reach_check.sh + bats — invert the skew rule ("status past draft, unregistered" becomes the normal state, not the failure).
    3. Flip personas/solution-architect/persona.yml to status: canary, remove its now-forbidden canary block, and run the scored eval gate — which has still never been run against this persona.

    Blocked until #1693 and combsmith/.github#1082 merge, since 1 and 2 must cite an accepted ADR rather than anticipate one.

  11. don-petry
    added 2 commits that reference this issue on Sep 7, 2026

    fix(personas): unbreak validate-personas — drop canary blocks per ADR…

    e4cde24

    feat(personas): invert the reach check per ADR-0006 and promote solut…

    7054b67

  12. don-petry commented on Sep 7, 2026

    @don-petry
    don-petry
    on Sep 7, 2026
    Collaborator

    Delivered — solution-architect is promoted past draft

    PR #1705 merged. Verified against main just now, not asserted:

    status: canary

{"role":"solution-architect","status":"canary","surface_mention_only":true,
 "routes_via_router":true,"registered":false,"verdict":"promoted"}
::notice::solution-architect is promoted (unregistered by design, ADR-0006);
         the shared router serves its events and the surface stayed mention-only

OK: 9 persona manifest(s) valid, invariants hold.   (LIVE .github@main schema + LIVE canary-rings.json)
tests/persona_reach_check.bats — 17/17

    This is the first of nine personas to leave draft — the outcome the epic put promotion inside the scope to achieve, after eight prior onboardings each deferred it.

    AC disposition

    AC Status
    #1 + registry entry Superseded by ADR-0006, and the literal value was never valid — see below
    #2 ring soak Superseded — no per-persona channel tag exists to stage
    #3 #1592 posture documented Met (PR #1664)
    #4 propagation verified against a real consumer Met — persona_reach_check.sh + the live mention in soak #1640
    #5 no new trigger surface Met — surface_mention_only: true, enforced by the guard

    AC #1 could never have passed as written. persona.schema.json's status enum is draft|canary|ring0|ring1|stable|retired — there is no next, though the registry channel and PRC_RING_ORDER both use that word. status: next fails schema validation. The persona is at canary, the legal first step past draft. That vocabulary mismatch is pre-existing, is now pinned by a test, and deserves its own decision — filed separately, not silently reconciled.

    What is deliberately NOT done

    stable requires the scored eval gate (evals.required_before: stable), and the scored eval has never been run against this persona. canary is a legitimate resting state. Running it is the next real step, and if it scores below threshold that is a finding worth having — the answer would be improving the advisory prompt, not lowering the bar.

    Closing as delivered.

  13. don-petry
    closed this as completedon Sep 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    dev-leadFor dev-lead agent pickupinitiativeEpic / initiative tracking issue

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions