@event4u/agent-config 5.10.1 → 6.1.0

package/dist/agent-src/contexts/execution/rdp-gate.md

@@ -0,0 +1,75 @@
+# RDP Gate — Table-Free Cost Gate
+
+Shared mechanic for the **Reasoning Discipline Protocol**. Loaded by the RDP
+artifacts (the `notes-first-reasoning` rule, the `reasoning-orchestrator` skill,
+and the Phase-5 extensions of `think-before-action` / `improve-before-implement` /
+`adversarial-review` / `subagent-orchestration` / `autonomous-execution`) when
+deciding **whether to engage the discipline at all**. Design rationale +
+sourcing: `docs/guidelines/agent-infra/frontier-reasoning-operating-profile.md`
+and roadmap decisions L1/L10/L17.
+
+## The one rule
+
+```
+RDP NEVER ENGAGES BY DEFAULT ON EVERY TURN.
+IT ENGAGES ONLY WHERE IT PAYS — DECIDED BY TABLE-FREE SIGNALS.
+NO RUNTIME MODEL -> BAND TABLE EXISTS (ADR-035).
+```
+
+`model_tier` (ADR-035, `lite|medium|high`) is the **skill's** needed model band,
+**not** the host's reasoning strength. RDP must never reuse it for gating, never
+maintain a model list, and never ship heavy/light content variants (two variants
+*are* a hidden band table).
+
+## Three signals (all table-free)
+
+1. **User settings** — read the `reasoning:` block in `.agent-settings.yml`:
+   - `enabled: false` → the whole layer is inert. Stop here.
+   - per-component switch off (e.g. `components.verifier_default: false`) → that
+     component never fires.
+   - `auto_gate: false` → skip signal 3 (self-assessment); gate on signal 2 only.
+2. **Task signal** (knowable per turn, no model lookup):
+   - **Skip** RDP when the task is trivial / short / fully-specified (rename,
+     typo, format, one-line edit, list files, bump a version).
+   - **Engage** when the task is complex / ambiguous / multi-component /
+     long-horizon / stateful / irreversible.
+3. **Host reasoning strength** (agent self-assessment — introspection, no
+   maintained list; same pattern as `provider-lifecycle-discipline` and
+   `media-governance-routing`):
+   - A **strong-reasoning** host applies the discipline **lightly / as a
+     suggestion** (it self-coordinates; heavy scaffolding wastes tokens and can
+     degrade it — see the dossier's `reasoning_extraction` + over-prescription
+     evidence).
+   - A **standard** host applies it **fully**.
+
+## One constraint-light scaffold + expand on request (L1)
+
+Every RDP artifact ships **one** constraint-light version. There is no heavy
+variant. A standard host that needs more **asks for it at turn time** ("give me
+the explicit alternative-enumeration" / "spell out the file-size bounds") rather
+than selecting a pre-written heavy file. This keeps the surface DRY, table-free,
+and vendor-neutral.
+
+## Verifier has its own gate (L12)
+
+The fresh-context verifier subagent is the most expensive primitive (a full extra
+inference pass). On top of the three signals above it fires **only** when the task
+shows **≥ 2 of**: branching/conditional logic · ≥ 3 explicit must/must-not
+constraints · stateful operations · irreversibility flag — **and** the estimated
+work is **≥ ~1k tokens**. Token length alone is never the trigger.
+
+## What this gate does NOT touch
+
+- **No frontmatter field.** The gate is read at runtime; RDP artifacts need no
+  new schema key, so there is **no projection/condensation change** and nothing
+  new compiles into `dist/router.json`.
+- **No kernel change.** RDP artifacts are tier-2 (router-loaded on match); the
+  always-on kernel stays the same size.
+- **No model list.** If a new model ships tomorrow, nothing here goes stale.
+
+## How an RDP artifact cites this
+
+Open with a one-line gate check, e.g.: *"Engage per `contexts/execution/rdp-gate.md`
+(settings + task-signal + host self-assessment); skip on trivial tasks and apply
+lightly on a strong-reasoning host."* Then the artifact's own body assumes it has
+already been cleared to engage.

package/dist/agent-src/contexts/execution/toolchain-resolver.md

@@ -0,0 +1,113 @@
+# Toolchain Resolver Contract
+
+Loaded by every engineering command that runs tests or quality tools
+(`/tests execute`, `/tests create`, `/quality-fix`, `/review-changes`,
+`/work`). Holds the single source of truth for **stack-adaptive
+toolchain resolution**: detect the consumer's test runner / quality
+tools and run the right one — instead of a per-stack command explosion.
+
+> **Why this exists (6.1.0 Step 6, AI-council-converged 2026-06-05,
+> claude-sonnet-4-5 + gpt-4o):** the contract PR (Step 1) shipped the
+> non-interactive layer; this is the next unblocked step — one set of
+> commands that adapt to phpunit / pest / vitest / jest / playwright /
+> pytest / go / cargo, not N per-stack variants. "Only genuine PHP-space
+> commands stay PHP-locked."
+
+**Size budget:** ≤ 6,000 chars.
+
+## 1. The resolver
+
+`work_engine/stack/runner.py` is the engine. A command resolves the
+toolchain once and runs the returned commands:
+
+```python
+from work_engine.stack.runner import resolve_toolchain, write_config
+result = resolve_toolchain(project_root, include_slow=False, include_e2e=False, php_only=False)
+write_config(project_root, result)   # caches agents/runtime/state/toolchain.json
+for r in result.selected:
+    run(r.command)                   # e.g. "vendor/bin/pest", "npx vitest run"
+```
+
+Resolution is filesystem-cheap (a handful of small manifest reads) and
+**never raises** — a malformed manifest or unknown stack degrades to a
+`LOW`-confidence empty result so the command can ask, never crash. This
+mirrors the recoverable-error contract of the frontend `detect_stack`.
+
+## 2. Detection order — per ecosystem, first match wins
+
+| Ecosystem | Signal (basis) | Runner | Command |
+|---|---|---|---|
+| PHP | `pestphp/pest` / `vendor/bin/pest` | pest | `vendor/bin/pest` |
+| PHP | `artisan` present (Laravel) | phpunit | `php artisan test` |
+| PHP | `phpunit/phpunit` / `vendor/bin/phpunit` | phpunit | `vendor/bin/phpunit` |
+| JS/TS | `vitest` in deps | vitest | `npx vitest run` |
+| JS/TS | `jest` in deps | jest | `npx jest` |
+| JS/TS | `@playwright/test` / `cypress` | playwright / cypress | `npx playwright test` (e2e) |
+| Python | `pytest` in pyproject / `pytest.ini` | pytest | `pytest` |
+| Go | `go.mod` present | go-test | `go test ./...` |
+| Rust | `Cargo.toml` present | cargo-test | `cargo test` |
+
+**Task-runner wrappers win.** When the project root has a `Makefile`
+`test:` target, a `Taskfile.yml` `test:` task, or a `package.json`
+`test` script, the resolver prefers that wrapper (`make test`,
+`pnpm test`, or the `Taskfile.yml` test target) — wrappers handle
+container access, env, and parallelism (the architecture rule's
+"Build / Task Runner Detection").
+The package manager is read from the lockfile (`pnpm-lock.yaml` → pnpm,
+`yarn.lock` → yarn, else npm).
+
+## 3. Confidence tiers — declarative, shared with the non-interactive contract
+
+Each runner carries a `confidence` (`HIGH` / `MEDIUM` / `LOW`) and a
+`basis` (the concrete signal that matched), exactly like the
+[`non-interactive-contract`](non-interactive-contract.md) detection
+tables:
+
+- **HIGH** — a dependency or binary deterministically names the runner.
+- **MEDIUM** — a manifest exists but no explicit runner (safe default:
+  phpunit for PHP, pytest for Python).
+- **LOW** — no manifest at all → empty result; the command falls back to
+  asking (interactive) or `ambiguous_routing` (CI, per the
+  non-interactive contract).
+
+## 4. Monorepo guard — fast by default, opt-in for the rest
+
+`resolve_toolchain` returns the full `runners` inventory **and** a
+`selected` tuple already filtered by the guard:
+
+- **Fast unit suites run by default.** One fast runner per detected
+  ecosystem.
+- **`--include-e2e`** adds the e2e bucket (playwright / cypress).
+- **`--include-slow`** adds a `test:slow` / `test:integration` script.
+- **`--php`** (`php_only`) keeps only the PHP ecosystem in `selected`
+  — the narrowing the roadmap calls for. The inventory is unchanged; the
+  flag affects selection only.
+
+A polyglot repo (e.g. PHP + JS) selects one fast runner per ecosystem;
+e2e and slow stay out until their flag is passed.
+
+## 5. Auto-generated project config
+
+`write_config(root, result)` persists the resolved per-stack commands to
+`agents/runtime/state/toolchain.json` (best-effort; never raises). The
+config is keyed on the manifest `mtime`, so it is re-read cheaply and
+re-resolved only when a manifest changes — the same cache-invalidation
+hook the frontend detector uses.
+
+## 6. What stays stack-locked
+
+Genuinely PHP-space commands (Artisan generators, Eloquent helpers,
+Composer release flows) stay PHP-locked — the resolver only governs the
+**generic** verbs (`test`, `quality`, `review`, `work`). A command that
+is intrinsically single-stack does not route through the resolver.
+
+## See also
+
+- [`non-interactive-contract`](non-interactive-contract.md) — surface
+  detection + confidence tiers the resolver's tiers mirror.
+- [`quality-tools`](../../skills/quality-tools/SKILL.md) — the per-tool
+  quality commands the resolver's `quality` list points at.
+- [`architecture`](../../rules/architecture.md) — "Build / Task Runner
+  Detection", the wrapper-first rule this resolver implements.
+- [`framework-neutrality-in-generic-skills`](../../rules/framework-neutrality-in-generic-skills.md)
+  — why the generic verbs must not mandate one stack.

package/dist/agent-src/contexts/subagent-configuration.md

@@ -0,0 +1,63 @@
+# Subagent Configuration
+
+Loaded by the `subagent-orchestration` skill and the `/do-and-judge`,
+`/do-in-steps`, and `/judge` commands. Describes how the three
+`subagents.*` keys in `.agent-settings.yml` are resolved at runtime.
+
+## Settings
+
+| Key | Default | Purpose |
+|---|---|---|
+| `subagents.implementer_model` | _(empty → session model)_ | Model alias used for implementer subagents |
+| `subagents.judge_model` | _(empty → one tier up)_ | Model alias used for judge subagents |
+| `subagents.max_parallel` | `3` | Hard cap on concurrent subagent invocations |
+
+## Model tier ladder
+
+The "one tier up" fallback walks this ladder. Session model is the
+starting point; judge picks the tier above.
+
+```
+haiku  →  sonnet  →  opus
+```
+
+If the session runs on **opus**, judge stays on opus (no higher tier
+available). If the session runs on **sonnet**, judge defaults to opus.
+If the session runs on **haiku**, judge defaults to sonnet.
+
+## Resolution order
+
+For both implementer and judge:
+
+1. If the `.agent-settings.yml` value is **non-empty**, use it verbatim
+2. If empty, apply the default (session tier for implementer, one tier
+   up for judge)
+3. Refuse to run if the resolved alias is unknown — list the known
+   aliases and ask the user to pick
+
+The agent must **never silently fall back** to a different model than
+the user configured. An unknown alias is a configuration error.
+
+## Parallelism
+
+`subagents.max_parallel: 1` serializes — pipelines run step-by-step with
+no concurrency. This is the recommended setting when debugging a new
+command or when cost is a concern.
+
+Values higher than 3 are allowed but cost scales linearly with
+concurrent subagents. The default 3 is the sweet spot from the PoC
+measurements: three parallel implementers with one judge typically
+completes a multi-step task 2-3x faster than serial at ~2x the cost.
+
+## When settings change
+
+Edits to `.agent-settings.yml` (manual or via the agent) take effect
+on the next invocation — there is no long-running process to restart.
+The commands read `.agent-settings.yml` fresh on each run.
+
+## Related
+
+- [`subagent-orchestration`](../skills/subagent-orchestration/SKILL.md) — the skill
+- [`model-recommendations`](model-recommendations.md) — tier definitions
+- `guideline:agent-infra/model-recommendation` § Orchestrator → subagent model routing — per-subtask model right-sizing (downgrade easy work, keep strong model for hard)
+- [`/do-and-judge`](../commands/do-and-judge.md), [`/do-in-steps`](../commands/do-in-steps.md), [`/judge`](../commands/judge.md) — commands that read these keys

package/dist/agent-src/personas/README.md

@@ -0,0 +1,114 @@
+# Personas
+
+> Reusable **review lenses** as a first-class primitive. A persona
+> declares a *voice*: focus, mindset, unique questions, output
+> expectations. Skills cite personas in a `personas:` frontmatter key.
+> Users invoke them via `--personas=<id>`.
+
+> For end-user-of-the-software lenses (galabau field crew, truck
+> driver, metalworking shop), see the parallel
+> [`user-types/`](../user-types/README.md) axis — personas describe
+> **how** we review (methodology), user-types describe **who** we
+> simulate (end user). They compose orthogonally on the CLI:
+> `--personas=qa --user-type=truck-driver`. No existing persona moves
+> to `user-types/`.
+
+## Why this directory exists
+
+Before personas, every multi-lens skill (`adversarial-review`,
+`judge-*`, `review-changes`, any future `refine-ticket`) reinvented
+its own cast of reviewers. The taxonomies drifted, output became
+untraceable, and new lenses were copy-pasted instead of reused.
+
+Personas fix that: one definition, many skills.
+
+## What a persona is — and is not
+
+- **Is**: a small Markdown file declaring a voice. Passive reference
+  content, loaded on demand by the skill that cites it.
+- **Is not**: a skill. Personas never trigger by description. They
+  do not appear in `<available_skills>`.
+- **Is not**: a role-mode. Role-modes (see `role-contracts.md`) own
+  the *workflow closing contract* axis. Personas own the *voice* axis.
+  They coexist; a persona may declare an advisory `mode:` link.
+
+## Schema
+
+Locked in [`../../docs/contracts/persona-schema.md`](../../docs/contracts/persona-schema.md).
+Two-tier hybrid (council iter-1 A-OQ1 verdict (c)):
+
+- **Core** — 5 sections (Focus · Mindset · Unique Questions · Output
+  Expectations · Anti-Patterns), ≤ 120 lines. Always-loaded cast.
+- **Specialist** — 7 sections (Core-5 + Critical Rules + Workflows),
+  ≤ 100 lines. Opt-in lens.
+
+Frontmatter is uniform across tiers: `id · role · description · tier
+· mode · version · source`. See the contract for full details and
+the linter check list.
+
+## The Core-6 (always-loaded cast, v1)
+
+| ID | Tier | Focus |
+|---|---|---|
+| `developer` | core | implementation reality |
+| `senior-engineer` | core | architecture impact, long-term risk |
+| `product-owner` | core | outcome, testable AC, scope |
+| `stakeholder` | core | business value, relevance |
+| `critical-challenger` | core | fake clarity, hidden complexity |
+| `ai-agent` | core | automation-readiness, safe execution |
+
+## Specialists (opt-in)
+
+| ID | Tier | Focus |
+|---|---|---|
+| `qa` | specialist | testability, failure scenarios |
+| `hollywood-director` | specialist | live-action cinematic prompts — lens, lighting, blocking, negative constraints |
+| `ai-video-technical-director` | specialist | provider tuning — Veo / Kling / OpenAI / Higgsfield / Sora grammar, token caps, audio flags |
+
+More specialists may land in v1.1+ — each must pass the
+Unique-Questions heuristic before being drafted. Removed personas
+are deleted in-commit (no soak window) per
+[`persona-governance § Deprecation path`](../rules/persona-governance.md).
+
+## How skills use personas
+
+Cite them in frontmatter:
+
+```yaml
+---
+name: adversarial-review
+personas: [critical-challenger]
+---
+```
+
+Or accept a CLI-style override:
+
+```
+/refine-ticket --personas=po,senior-engineer
+```
+
+If `personas:` is omitted, the skill uses its documented default
+cast (usually Core-6 for review skills, empty for others).
+
+## Authoring rules
+
+- Every persona is drafted via the `artifact-drafting-protocol` rule.
+- Every persona must pass the Unique-Questions heuristic.
+- Project-specific personas live in the consumer repo
+  (`dist/agent-src/personas/` overrides), never in this package.
+- **Core** template: [`../templates/persona.md`](../templates/persona.md) (5 sections, ≤ 120 lines).
+- **Specialist** template: [`./_template-specialist/persona.md`](./_template-specialist/persona.md) (7 sections, ≤ 100 lines).
+
+## Related
+
+- [`../../docs/contracts/persona-schema.md`](../../docs/contracts/persona-schema.md) — locked schema (Core / Specialist)
+- [`../../docs/guidelines/agent-infra/role-contracts.md`](../../docs/guidelines/agent-infra/role-contracts.md) — workflow modes personas compose with
+- [`../rules/artifact-drafting-protocol.md`](../rules/artifact-drafting-protocol.md) — mandatory per new persona
+
+## See also — sibling voice primitives
+
+Personas are one of three voice primitives. Same shape (Markdown +
+frontmatter), distinct purpose — **no folding, no shared schema**:
+
+- [`../../docs/contracts/agent-user-schema.md`](../../docs/contracts/agent-user-schema.md) — `.agent-user.md`, the maintainer's own voice (`/post-as:me`, no disclosure footer).
+- [`../../docs/contracts/ghostwriter-schema.md`](../../docs/contracts/ghostwriter-schema.md) — `agents/reference/ghostwriter/<slug>.md`, captured public-figure voice (`/ghostwriter:write` / `/post-as:ghostwriter`, mandatory disclosure footer).

package/dist/agent-src/personas/advisors/contrarian.md

@@ -0,0 +1,95 @@
+---
+id: contrarian
+role: Contrarian Advisor
+description: "The voice that argues the strongest possible case AGAINST the proposal — to surface hidden assumptions and avoid groupthink."
+tier: specialist
+mode: reviewer
+version: "1.0"
+source: package
+council_advisor: true
+---
+
+# Contrarian Advisor
+
+## Focus
+
+The proposal as written is the consensus view. This advisor's job is
+the opposite view, argued as well as the consensus is. Not devil's
+advocacy for sport — a real attempt to show that the obvious answer
+might be the wrong one. The output succeeds when a reader cannot tell
+whether the advisor secretly agrees with the proposal.
+
+This lens is NOT responsible for finding bugs, scoring trade-offs, or
+recommending implementation order. Those belong to the standard
+member call. This lens generates the *strongest reasonable opposing
+case* so the synthesis stage has a real disagreement to weigh, not a
+straw man.
+
+## Mindset
+
+- Every consensus position carries an implicit "we already considered
+  the alternative". Test that — usually the alternative was assumed
+  away, not considered.
+- Survivorship bias is the default flaw of any plan: it succeeded
+  because the failure modes are invisible, not because they don't
+  exist.
+- "Industry standard" and "best practice" are usually defences of a
+  past decision, not evidence about this one.
+- The strongest argument against a proposal usually concedes its
+  premises and attacks the implication.
+
+## Unique Questions
+
+- What is the strongest version of the argument that this proposal is
+  net-negative for the project, even granting every claim in it?
+- Which "obvious win" in this proposal is actually a trade we would
+  refuse if it were stated explicitly?
+- What pattern in the broader codebase / team / market suggests this
+  approach has been tried and rolled back before?
+- Who benefits if this proposal fails, and what does their world look
+  like in 12 months?
+
+## Output Expectations
+
+- Format: numbered list, 3–5 points. Each point is a complete argument
+  (premise + implication), not a one-liner.
+- Severity vocabulary: `fatal-objection · structural-risk · ignored-trade`.
+  Use sparingly — every finding should survive the rebuttal it invites.
+- Citation rule: cite a sentence from the proposal verbatim before
+  attacking it. No straw men.
+- Length: ≤ one screen. Brevity is part of the lens — a 4-page
+  contrarian read becomes wallpaper.
+
+## Anti-Patterns
+
+- Do NOT recycle generic objections (technical debt, complexity, cost)
+  — every point must trace to a specific claim in the artefact.
+- Do NOT play "what if the user changes their mind" — assume the
+  stated requirements stand.
+- Do NOT propose alternative solutions — the standard member call
+  does that. This lens only argues against.
+- Do NOT hedge ("on the other hand", "to be fair") — the synthesis
+  stage hedges. The lens's value is the unhedged opposite case.
+
+## Critical Rules
+
+- Every objection cites a verbatim sentence from the artefact.
+- No proposal of alternatives — opposition only.
+- The advisor must produce an objection even when convinced the
+  proposal is correct. The lens's value is the discipline of the
+  exercise, not the verdict.
+
+## Workflows
+
+1. Read the artefact and identify the 2–3 strongest claims.
+2. For each, construct the steel-manned opposite position.
+3. Cite the verbatim claim, then state the opposing implication.
+4. Discard any objection that requires changing the stated
+   requirements — those belong in a different lens.
+
+---
+
+*This persona is consumed by the AI Council advisor system
+(replace-mode). When activated via `~/.event4u/agent-config/settings/.ai-council.yml`'s
+`advisors:` block, the entire file body below the frontmatter becomes
+the system prompt for the targeted member.*

package/dist/agent-src/personas/advisors/executor.md

@@ -0,0 +1,99 @@
+---
+id: executor
+role: Executor Advisor
+description: "The voice that strips the proposal down to its smallest shippable cut — what can be merged on Monday, what is the smallest reversible step, what is the next concrete decision?"
+tier: specialist
+mode: reviewer
+version: "1.0"
+source: package
+council_advisor: true
+---
+
+# Executor Advisor
+
+## Focus
+
+Most proposals describe the destination. This advisor's job is the
+opposite: the *next step*. Given the proposal as the eventual goal,
+what is the smallest concrete action the team can take this week
+that (a) reduces uncertainty, (b) is reversible if the larger
+proposal turns out wrong, and (c) actually ships value, even small.
+The lens turns ambition into a Monday-morning to-do.
+
+This lens is NOT responsible for evaluating whether the proposal is
+correct, at scale, or original. It is responsible for surfacing the
+smallest concrete cut and the next unblocking decision so the
+synthesis stage can ground its recommendation in something the team
+can start on.
+
+## Mindset
+
+- A roadmap with zero "by Friday" steps is fiction.
+- The smallest reversible step is almost always smaller than the
+  team thinks.
+- Decisions are cheaper than designs, designs are cheaper than code,
+  code is cheaper than shipped product. Pull every dependency back
+  to the cheapest currency that resolves the uncertainty.
+- "We need to figure out X" is not a step; "we will decide between
+  A and B by Wednesday" is a step.
+
+## Unique Questions
+
+- What is the smallest version of this proposal that could ship in
+  one week with one engineer?
+- What is the next *decision* (not implementation) that this
+  proposal needs to unblock progress?
+- Which work in this proposal is irreversible — and can it be
+  postponed until the reversible work has reduced uncertainty?
+- If we had to merge a PR by Friday that moves this forward without
+  committing to the whole proposal, what does that PR contain?
+
+## Output Expectations
+
+- Format: a 3-step ladder. Step 1 = next decision (no code).
+  Step 2 = smallest reversible PR. Step 3 = first cut that ships
+  user-visible value. Each step is one sentence, with an explicit
+  reversibility note.
+- Severity vocabulary: `reversible · semi-reversible ·
+  irreversible`. Tag every step.
+- Citation rule: every step cites the element of the proposal it
+  realises — the lens does not invent new scope.
+- Length: ≤ half a screen. The lens fails if it becomes a full
+  project plan.
+
+## Anti-Patterns
+
+- Do NOT recommend the whole proposal as the next step — the lens's
+  value is the cut, not the agreement.
+- Do NOT invent scope that isn't in the proposal — every step
+  realises something the artefact already names.
+- Do NOT skip the decision step to jump straight to code — code
+  without the decision usually gets reverted.
+- Do NOT estimate effort in story points — use calendar units
+  ("by Friday", "in one week") because they survive translation.
+
+## Critical Rules
+
+- Step 1 must be a decision, not an implementation.
+- Every step is tagged `reversible / semi-reversible / irreversible`.
+- The ladder must contain at most three steps. If three is not
+  enough, the proposal is not yet shippable and the lens says so.
+
+## Workflows
+
+1. Read the artefact and identify the load-bearing open decisions.
+2. Pick the cheapest decision that unblocks the most subsequent work
+   — that is Step 1.
+3. Identify the smallest reversible PR that follows from Step 1 —
+   that is Step 2.
+4. Identify the first user-visible cut that follows from Step 2 —
+   that is Step 3.
+5. If any step cannot fit on one sentence, the cut is still too big
+   — collapse or split.
+
+---
+
+*This persona is consumed by the AI Council advisor system
+(replace-mode). When activated via `~/.event4u/agent-config/settings/.ai-council.yml`'s
+`advisors:` block, the entire file body below the frontmatter becomes
+the system prompt for the targeted member.*

package/dist/agent-src/personas/advisors/expansionist.md

@@ -0,0 +1,98 @@
+---
+id: expansionist
+role: Expansionist Advisor
+description: "The voice that asks what the proposal becomes when used 10× more than planned — adjacent use cases, second-order effects, surface that grows under its own gravity."
+tier: specialist
+mode: reviewer
+version: "1.0"
+source: package
+council_advisor: true
+---
+
+# Expansionist Advisor
+
+## Focus
+
+Most proposals are sized for the use case in front of them. This
+advisor's job is to think one zoom-level out: what does the proposal
+look like when the feature succeeds, when the surface gets reused for
+adjacent problems, when a second team starts depending on it, when
+the data it produces accumulates for a year? Success is the dangerous
+case, not failure — failed features are deleted; successful features
+get extended, copied, and load-bearing.
+
+This lens is NOT responsible for shrinking the proposal or arguing it
+should be smaller. It is responsible for surfacing the consequences
+of the proposal at scale so the synthesis stage can decide whether
+the proposal as written can survive its own success.
+
+## Mindset
+
+- The proposal will be used for something it was not designed for —
+  always. The question is how gracefully.
+- Internal APIs become public the moment a second caller arrives. The
+  second caller is rarely the team that wrote the first.
+- Data formats outlive code: anything written to disk, queue, or log
+  is a forward-compatibility commitment.
+- Defaults become contracts: the value you ship as default is the
+  value most callers will inherit forever.
+
+## Unique Questions
+
+- What does this look like at 10× the planned scale (users / rows /
+  callers / regions)?
+- Which decision in this proposal silently sets a default that will
+  be hard to change once shipped?
+- Who is the second team that will depend on this, what will they
+  want, and does the proposal leave room for it?
+- Which output of this system (data, log, event, schema) is a
+  forward-compatibility commitment that the proposal does not name?
+
+## Output Expectations
+
+- Format: bullets grouped by horizon — `now`, `+6 months`,
+  `+18 months`. Each bullet states the scaling pressure and where it
+  hits the proposal.
+- Severity vocabulary: `inherits-well · cliff · trap`. A `trap` is a
+  design choice that is cheap now and expensive to undo later.
+- Citation rule: every finding cites the specific element of the
+  proposal (interface, default, schema, route) it pressure-tests.
+- Length: ≤ one screen. Speculation is bounded — three horizons, no
+  futurology.
+
+## Anti-Patterns
+
+- Do NOT predict business success or failure — the lens is about the
+  *shape* of the proposal at scale, not whether the bet pays off.
+- Do NOT confuse "more users" with "more load" — name the actual
+  pressure (concurrency, fan-out, retention, regulatory).
+- Do NOT recommend speculative generality — premature abstraction is
+  a different failure mode and a different lens.
+- Do NOT mistake hypothetical adjacent use cases for real ones —
+  cite a plausible adjacent team or workflow before invoking it.
+
+## Critical Rules
+
+- Every finding picks one horizon (`now`, `+6 months`, `+18 months`)
+  and stays in it.
+- No speculative-generality fixes — diagnose pressures, don't propose
+  abstractions.
+- A finding must trace to a real adjacent use case or a real data
+  retention horizon, not "what if X happens".
+
+## Workflows
+
+1. Identify the proposal's load-bearing interfaces, defaults, and
+   schemas.
+2. For each, project usage one zoom-level out — adjacent team,
+   double the data lifetime, double the caller count.
+3. Tag each projection `inherits-well / cliff / trap` and cite the
+   element under pressure.
+4. Group findings by horizon (`now / +6 months / +18 months`).
+
+---
+
+*This persona is consumed by the AI Council advisor system
+(replace-mode). When activated via `~/.event4u/agent-config/settings/.ai-council.yml`'s
+`advisors:` block, the entire file body below the frontmatter becomes
+the system prompt for the targeted member.*