Skip to content

Register agents.solution-architect in canary-rings.json (cross-repo prerequisite for .github-private#1631) #1078

Closed as not planned
Closed as not planned
Register agents.solution-architect in canary-rings.json (cross-repo prerequisite for .github-private#1631)#1078
Labels
dev-leadFor dev-lead agent pickupenhancementFeature requests

Description

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

Cross-repo prerequisite for combsmith/.github-private#1631 — [Phase 4] Promote solution-architect past draft through the release rings, verifying propagation reached a consumer, the last open story of epic combsmith/.github-private#1627 — Onboard solution-architect as an addressable advisory persona (repo-local first cut).

Everything else in that epic is delivered. This registry entry lives here, not in .github-private, so dev-lead cannot make it from the other repo — it is the one remaining blocker, and it is why the story has sat open since 2026-09-03.

What is being asked

Add one agents.solution-architect entry to standards/canary-rings.json, per standards/persona-standards.md §6 step 2, so the persona can advance draft → next and soak the rings.

Current state (verified 2026-09-07)

  • agents.solution-architect is not in canary-rings.json (16 agents registered; neither solution-architect nor qa-lead is among them).
  • personas/solution-architect/persona.yml on .github-private main is still status: draft.
  • The persona is otherwise complete and working: manifest + interaction.yml + prompts/solution-architect/advisory.md, the petry-projects/solution-architect team (closed, notifications disabled, 0 members), real held-out evals, a scored eval gate, and a live smoke test in which it cited ADR-0001 by number and caught two planted violations.

Read this before implementing — the entry does not fit the schema cleanly

Every one of the 16 registered agents has a reusable. solution-architect deliberately has none. It is served by the shared, convention-driven persona runtime: the persona-mention router (registered here) dispatches to persona-runner-reusable.yml in .github-private, which runs any persona that supplies a manifest plus prompts/<role>/advisory.md. That shared runtime is the entire reason onboarding a persona is now cheap; it also means there is no per-persona blob for the ring model to watch.

That matters because the rollout machinery is built around reusable blobs: canary-rollout.sh autocut cuts a version "when a reusable's blob on its host main HEAD differs from the current next candidate," and canary-rollout.sh drift reports *-reusable.yml files that are unregistered.

Relevant fact for whoever implements this: persona-runner-reusable.yml is currently not registered at all, while persona-mention-reusable.yml is registered as agents.persona-mention.

Recommendation

Register agents.solution-architect with host: petry-projects/.github-private and reusable: .github/workflows/persona-runner-reusable.yml — the reusable that actually executes this persona — mirroring agents.persona-mention's rings[] and gate block so ring membership and soak knobs stay consistent with the runtime that serves it.

Two consequences to write into the entry as comments rather than discover later:

  1. Autocut will not fire on this persona's own changes. Its behavior lives in prompts/solution-architect/advisory.md, checked out at the pinned agent_ref — a prompt-only change never moves the runner's blob. That is Script-only changes never reach the fleet: autocut watches the reusable blob, but agents execute scripts/ pinned at agent_ref .github-private#1592 — Script-only changes never reach the fleet, and it is precisely why the story does not treat a ring label as evidence of promotion. scripts/persona_reach_check.sh in .github-private is the compensating control: it separates routes-to from promoted and fails on the skew state.
  2. This sets fleet precedent. Eight other personas are drafted behind the same shared runtime. If each later registers against the same reusable, several agents end up watching one blob — one change would cut several versions. Decide deliberately now rather than by accumulation.

If the maintainer prefers the alternative — that personas on a shared runtime inherit the runtime's rings and are not individually registered — that is defensible and arguably truer to the mechanism, but it is a standards change, not a config change: persona.schema.json requires canary.agent, and §6 step 2 requires the entry. In that case close this issue and raise the standards amendment instead; do not silently skip the registration.

Acceptance criteria

  1. standards/canary-rings.json contains an agents.solution-architect entry with host, reusable, run_workflow, rings[], and gate, valid against the file's existing shape and consistent with agents.persona-mention's rings/gate.
  2. The entry carries an inline _note recording (a) that this persona has no dedicated reusable and rides the shared persona runtime, and (b) that autocut will not fire on prompt-only changes, naming Script-only changes never reach the fleet: autocut watches the reusable blob, but agents execute scripts/ pinned at agent_ref .github-private#1592 and pointing at scripts/persona_reach_check.sh as the compensating control.
  3. next ring membership is petry-projects/.github-private (the dogfood ring), matching agents.persona-mention.
  4. JSON parses and any existing registry validation / canary_rollout.bats remains green.
  5. Do not flip personas/solution-architect/persona.yml here — that file is in .github-private and is the other half of [Phase 4] Promote solution-architect past draft through the release rings, verifying propagation reached a consumer .github-private#1631. The two land together; the reach-check fails on the skew state (status past draft with no registry entry), so this entry must merge first or with it.

Out of scope

Registering the other eight drafted personas; registering qa-lead; any change to persona-standards.md; the draft → next manifest flip and the ring soak (all in .github-private).

Parent epic: combsmith/.github-private#1627 · Blocking story: combsmith/.github-private#1631 · Standard: standards/persona-standards.md §6, §7

Activity

  1. don-petry
    added
    enhancementFeature requests
    dev-leadFor dev-lead agent pickup
    on Sep 7, 2026

  2. don-petry commented on Sep 7, 2026

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

    Dev-Lead Implementation Plan

    Issue: #1078 — Register agents.solution-architect in canary-rings.json (cross-repo prerequisite for .github-private#1631)

    Scope

    Add one agents.solution-architect entry to standards/canary-rings.json, registered against the shared persona runtime (.github-private/.github/workflows/persona-runner-reusable.yml), mirroring agents.persona-mention's rings/gate, with an inline _note documenting the shared-runtime / no-dedicated-reusable and prompt-only-autocut consequences.

    Implementation Checklist

    • Add agents.solution-architect to standards/canary-rings.json with host: petry-projects/.github-private, reusable: .github/workflows/persona-runner-reusable.yml, run_workflow: Persona Runtime (the persona-runner.yml caller name — verified against .github-private main), rings[] (next→ring0→ring1→stable) and gate mirroring agents.persona-mention
    • next ring = petry-projects/.github-private (the dogfood ring), matching agents.persona-mention (AC Add coding standards & principles section to AGENTS.md #3)
    • Add inline _note per AC Add multi-agent isolation strategy using git worktrees #2: (a) no dedicated reusable — rides the shared persona runtime; (b) autocut will not fire on prompt-only changes — names .github-private#1592 and points at scripts/persona_reach_check.sh as the compensating control
    • Do NOT touch personas/solution-architect/persona.yml (lives in .github-private; AC Add stacked PR strategy and Epic-level workflow guidance #5) or any other file

    Tests to Write

    • New bats test in tests/canary_rollout.bats: canary-rings.json: solution-architect onboarded (shared persona runtime, no dedicated reusable, #1078) — asserts host, reusable, run_workflow, ordered rings, next = .github-private, gate consistent with persona-mention (ring1->stable sample_min==1; no correctness/suspect blocks), and presence of the _note naming #1592 + persona_reach_check.sh

    Test Command

    npx bats --print-output-on-failure tests/canary_rollout.bats (plus bash .dev-lead/scripts/dev-lead-lint.sh)

  3. don-petry commented on Sep 7, 2026

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

    Dev-Lead: Implementation Complete

    Plan Execution

    • Added agents.solution-architect to standards/canary-rings.json (host petry-projects/.github-private, reusable .github/workflows/persona-runner-reusable.yml, run_workflow: "Persona Runtime", rings[] + gate mirroring agents.persona-mention)
    • next ring = petry-projects/.github-private (dogfood ring), matching agents.persona-mention (AC Add coding standards & principles section to AGENTS.md #3)
    • Inline _note documents (a) no dedicated reusable / rides the shared persona runtime, and (b) autocut will not fire on prompt-only changes — names .github-private#1592 and points at scripts/persona_reach_check.sh as the compensating control (AC Add multi-agent isolation strategy using git worktrees #2)
    • Left personas/solution-architect/persona.yml untouched (it lives in .github-private; AC Add stacked PR strategy and Epic-level workflow guidance #5)
    • Added - solution-architect to the canary-rollout.yml workflow-dispatch agent enum (a registered agent MUST be dispatchable — this coupling is asserted by an existing bats test, so it is required to keep the registry validation green, AC Add workflow, environment, and orchestration guidance #4)
    • Added a TDD bats test for the new entry (written failing first, then made green)

    Determination of run_workflow

    Verified against petry-projects/.github-private main: persona-runner-reusable.yml is the shared runner; its caller is .github/workflows/persona-runner.yml whose display name is Persona Runtime — that is the workflow the gate samples on the ring tiers (the same "caller-stub name" convention agents.persona-mention uses with "Persona — Mention Router").

    Test Results

    $ npx bats tests/canary_rollout.bats
316 ok, 0 failures   (was 315; +1 new test)

$ npx bats --filter "solution-architect onboarded|agent choice list agrees" tests/canary_rollout.bats
ok 1 canary-rings.json: solution-architect onboarded on the shared persona runtime (no dedicated reusable, #1078)
ok 2 canary-rollout.yml: the agent choice list agrees with the registry (#1019)

$ bash .dev-lead/scripts/dev-lead-lint.sh
[lint] shellcheck on 34 file(s)...
[lint] validating .github/CODEOWNERS... OK
[lint] all checks passed   (exit 0)

    Files Changed

    • standards/canary-rings.json: +64 lines — new agents.solution-architect entry (purely additive; no existing lines modified). Entry's rings[]/gate are copied verbatim from agents.persona-mention (Define the release soak standard (ring-promotion gate): time floor + traffic-scaled sample + health #548 gate defaults, standard next→ring0→ring1→stable model, no opt-in correctness/suspect/benign machinery).
    • .github/workflows/canary-rollout.yml: +1 line — - solution-architect added to the manual-dispatch agent choice list (kept in agreement with .agents | keys).
    • tests/canary_rollout.bats: +38 lines — new test asserting host/reusable/run_workflow, ordered rings, next = .github-private, gate consistency with persona-mention, and the presence of the _note naming #1592 + persona_reach_check.sh.

    Notes

    • Acceptance criteria: 1 ✅ (entry valid + consistent with persona-mention), 2 ✅ (_note), 3 ✅ (next = .github-private), 4 ✅ (JSON parses; full canary_rollout.bats green), 5 ✅ (persona.yml not touched — it is the .github-private#1631 half; this entry must merge first or with it so persona_reach_check.sh does not see the skew state).
    • Scope note on the workflow enum: registering a new agent trips the existing enum ↔ registry agreement test, so the one-line canary-rollout.yml addition is a required consequence of the registration, not extra scope.
    • Out of scope (untouched): the other eight drafted personas, qa-lead, persona-standards.md, and the draft → next manifest flip / ring soak (all in .github-private).
    • No commits/pushes/PRs were made — the CI workflow handles git operations.

  4. don-petry commented on Sep 7, 2026

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

    Correction — this issue's premise was wrong

    I wrote an incorrect instruction into this issue, and PR #1079 faithfully implemented it. Flagging before it is copied into eight more entries.

    This issue told the implementer to record that "autocut will NOT fire on this persona's own prompt-only changes." That is false.

    It was written from combsmith/.github-private#1592 — Script-only changes never reach the fleet without verifying that premise still held. It does not. Per #1019, canary-rings.json carries a fleet-default agent_ref_paths of ["scripts/", "prompts/", "personas/"], and canary-rollout.sh _autocut_agent cuts when the reusable blob or any watched path changed. prompts/ is watched, so a prompt-only change does cut.

    Empirical proof: dev-lead — same host, same inherited paths — has 162 version tags and is at v139.8.0. Its reusable has not changed 139 times; watched-path changes drive nearly all of that.

    A second fact this issue did not account for: persona-runner.yml consumes the runtime by local relative path (uses: ./.github/workflows/persona-runner-reusable.yml) and the reusable declares no agent_ref input — so no caller pins a persona channel tag at all.

    What this means for #1079

    The entry is correct against this issue as written; the issue was wrong. Do not merge the _note as-is — it would assert something false in the fleet's single source of truth for rollout, and be copied eight more times.

    The full corrected problem statement, the verified evidence, and three options are in combsmith/.github-private#1688 — Decision: how should shared-runtime personas be represented in the canary ring model? That decision is being put to the solution-architect persona for an advisory, then to the maintainer. Holding #1079 until it resolves.

  5. don-petry commented on Sep 7, 2026

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

    Closing as not planned — the premise was wrong, and the corrected decision is ADR-0006 (approved in combsmith/.github-private#1688).

    This issue asked for an agents.solution-architect registry entry. That registration should not happen: a shared-runtime persona has no dedicated reusable, no caller pins a per-persona channel tag, and per the amended standard a registered persona id is a defect, not a promotion.

    Superseded by combsmith/.github-private#1693 (ADR-0006) and #1082 (schema + persona-standards.md §6/§7 in this repo). Implementation PR #1079 closed unmerged.

    My error, recorded so it is not repeated: I wrote the false autocut claim into this issue without verifying #1592's premise still held after #1019 added agent_ref_paths.

  6. don-petry
    closed this as not plannedon Sep 7, 2026
  7. don-petry
    added 2 commits that reference this issue on Sep 7, 2026

    feat: implement issue #1078 — Register agents.solution-architect in c…

    9abcaad

    docs(adr): ADR-0006 — shared-runtime personas are not individually ri…

    b5b76b4
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 pickupenhancementFeature requests

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions