Personas are noun taxonomies, not reviewers — add behavioral fields (silent checklist, blocking criteria) to members.yml

[minerva-sky]

Loop: loop:self · State: status:analyzed · Class: code-feature (L0 — proposing only)

Hypothesis

The multi-perspective review's output quality is capped by what the persona files actually encode. Today each member is four near-synonymous noun lists (specialties, disciplines, skillsets, domains) plus one perspective sentence. An LLM already knows what a "security specialist" is — the nouns add almost nothing it doesn't have. What it doesn't have is what THIS framework's security specialist should block on, ask first, and refuse to let pass. Adding per-member behavioral fields will produce measurably more differentiated, more actionable reviews.

Evidence

• Compare any two generated agents (agents/systems-architect.md vs agents/performance-specialist.md): they are interchangeable modulo nouns. No review methodology, no severity calibration, no example objection, nothing a reviewer could be wrong about.
• ADR-010 stakes the framework's identity on externalizing the "Silent Checklist" — the pattern-recognition questions seniors fire before coding. The Implementation Strategist's perspective line ("Is the system ready? Is the team ready?") is the one persona that gestures at this, and it's plausibly the persona users get the most distinctive value from. The other seven have no checklist at all.
• WORLD.md Direction: "Reviewer personas and the multi-perspective review are the differentiator. Deepen them before widening anything else." This is the deepening.

Proposed change (additive, backwards compatible)

New optional fields per member in members.yml, rendered by tools/lib/subagent-generator.js into the agent files:

• silent_checklist: — 3-5 questions this reviewer always asks first (ADR-010's language)
• blocking_criteria: — what makes this reviewer rate a concern critical; what they will not sign off on
• signature_tradeoff: — the axis this persona habitually trades against others (feeds the aggregator's Trade-offs section)

Fields absent → nothing rendered → every existing user .architecture/members.yml keeps working unchanged (WORLD.md backwards-compat constraint). Worked example for security_specialist:

silent_checklist:
  - "What new trust boundary does this change create or move?"
  - "Where does user-controlled data first touch this code path?"
  - "What happens when this component's secrets/config are wrong or leaked?"
blocking_criteria:
  - "Untrusted input reaching a filesystem path, shell, or query without validation"
  - "Auth decision made client-side or repeated inconsistently server-side"
signature_tradeoff: "security controls vs. performance overhead and onboarding friction"

Experiment

Run architecture-review twice on the same target (this repo's own mcp/ is a good subject), once with current personas, once with deepened ones. Measure: (1) pairwise finding overlap between members (deepened should be lower), (2) maintainer blind-rating of which run's critical findings are more actionable. Cheap to run, directly falsifiable. (Issue on per-finding disposition tracking, filed separately, would make this measurable on an ongoing basis rather than one A/B.)

Prior-art check

.architecture/deferrals.md Phase 4B defers "behavioral pattern refinement... without usage data" — that deferral is scoped to tuning pragmatic mode's existing question framework. This proposal addresses a structural absence (7 of 8 personas encode no behavior at all), and WORLD.md's Direction, written later, explicitly calls for it. Not re-raising a settled question; flagging the tension deliberately.

Cost

~30 lines in the generator + regenerating 8 agent files + authoring the behavioral content. The authoring is the real work and the part worth the maintainer's judgment — which is why this is an issue, not a PR: the checklist content IS the product (WORLD.md: "the markdown IS the product").

[minerva-sky]

Framing addendum, from Chad Fowler's "The Specification Is Not a Document" (Phoenix Architecture series, 2026-08-19 — https://aicoding.leaflet.pub/3mtgs36dnq22o), which lands squarely on this trio of issues (#35/#36/#37):

The behavioral fields proposed here are per-claim authority and provenance in Fowler's sense. A silent_checklist question is a claim ("this reviewer asserts X must be examined first"), and claims earn their keep through evidence, not plausibility. Practical consequence for the authoring work this issue flags as "the real product": record why each checklist question or blocking criterion exists — the incident, ADR, or observed failure that motivated it (a motivated-by edge, even if it's just a trailing parenthetical in members.yml). That does two things: it makes the checklist auditable rather than vibes, and once #37's dispositions exist, each question accrues an acceptance-rate trail — the mechanism for retiring questions that never earn their place instead of letting the checklist ossify.