cyber-aced 0.3.0

package/readme.md

@@ -0,0 +1,124 @@
+# ACED — Agent Config Evaluation & Development
+
+ACED is an SDD plugin specialized in **agent configuration** — the skills, `AGENTS.md` sections, subagent definitions, and commands that shape how AI agents behave.
+
+It applies spec-driven development to the agent configuration layer: author a frozen `.feature` suite (with inline `@rubric` scoring criteria), score agent behavior against it, catch regressions before they ship, and improve configurations until they pass.
+
+## What it does
+
+Agent configuration has the same failure modes as prompts: silent regressions, trigger mismatch, ambiguous rules, coverage gaps. Unlike code, there is no type-checker, linter, or test runner for it. ACED fills that gap.
+
+Evaluation runs in layers:
+
+| Layer | What it checks |
+|---|---|
+| **Structural** | Required fields and format (via `improve-skill`'s `validate.mts` engine) |
+| **Trigger** | Does the agent invoke this configuration at the right times? |
+| **Behavior** | When invoked, does the agent follow the steps and rules? |
+| **Quality** | Is the output actually good? |
+
+## When ACED fits (and when it doesn't)
+
+Not every agent configuration benefits from ACED. **Fit** = which of the four layers above carry
+real signal. ACED classifies each subject **in explore** (before authoring an eval suite) and
+records a `**Fit:**` line in its spec:
+
+| Fit | The subject… | ACED does |
+|---|---|---|
+| **strong** | makes a genuine activation decision + non-deterministic judgment | full eval — trigger near-misses required |
+| **partial** | mechanically executes a predetermined path (graded behavior, no activation choice) | behavior/quality evals; **no trigger near-miss** required |
+| **wrong-squad** | is a deterministic script/engine (assertable output, not graded) | **recuses** — use an ordinary test harness (`node:test`), not ACED |
+
+A second, independent axis — **`measured: worth | not-worth`** — says whether real headless runs
+(the measured layer, `bench`) answer a question simulation cannot. It is opt-in, declared under
+`bench:` in `eval.md`, and dollars never decide it.
+
+Only the **Structural** layer signal on a subject means it is **wrong-squad** — `improve-skill`'s
+`validate.mts` engine already covers that. The classifier lives in `skills/aced-fit/` (model: the
+spec's `design/fit.md`).
+
+## Skills
+
+| Skill | When to use |
+|---|---|
+| `init-aced` | Register ACED as the SDD plugin for agent-configuration domain types |
+| `add-scenario` | Add a new test case from a real failure or edge case |
+| `run` | Score the frozen `.feature` suite against the current agent configuration |
+| `compare` | Diff scores before/after an edit — regression gate |
+| `bench` | Measure a change with real headless runs (the measured layer) — plan, price, and run only on an explicit yes |
+| `improve` | Diagnose failing cases and propose targeted edits |
+| `report` | Project-wide health dashboard across all eval suites |
+
+Spec creation is owned by the `sdd` plugin's `start-mission` / `spec-gate`: once ACED is registered, the conductor resolves the ACED production-chain roles automatically. The `run`/`compare`/`add-scenario`/`report` skills are thin reporting over the frozen `.feature` suite.
+
+## Agents (production-chain roles)
+
+| Agent | Role |
+|---|---|
+| `aced-scenario-writer` | spec-producer — writes the spec.md body and the `.feature` (boolean scenarios, inline `@rubric` for graded behavior, `@trigger` `Scenario Outline` for activation) |
+| `aced-spec-validator` | spec-judge — judges the `.feature` against the agent-scenario criteria (incl. `@rubric` structure) |
+| `aced-impl-judge` | impl-judge — **runs** the frozen `.feature` suite (reading each scenario's inline rubric) over N runs, collapses to a boolean per scenario |
+| `aced-case-judge` | internal scorer for `aced-impl-judge` — scores one scenario on its inline rubric |
+
+The impl-producer (building the agent config to pass the frozen suite — the verification is the frozen `.feature` itself, not a separate eval suite) is the `define-agent` / `improve` skills or the SDD-default impl-producer (the conductor running `impl-producer-governance` via a spawned builder); ACED does not bind a solution-producer (SDD default).
+
+## Workflow
+
+```
+sdd:start-mission → sdd:spec-gate (spec gate) → implement → run/compare → improve
+                                                                   ↑
+                                                             add (new cases)
+                                                                   ↑
+                                                             report (project-wide)
+```
+
+1. **`sdd:start-mission`** — the conductor resolves `aced-scenario-writer` to write the `.feature`; `aced-spec-validator` judges it at the spec gate.
+2. **implement** — the impl-producer (`define-agent` / `improve`) builds the agent config to pass the frozen `.feature`; `aced-impl-judge` (impl-judge) **runs** the suite, scoring each scenario via `aced-case-judge` against its inline rubric and writing results to the shared `.agents/aced/results/` directory, keyed by target.
+3. **`compare`** — before committing an edit, diff the before/after scores. Warns on regressions.
+4. **`improve`** — reads failing scenarios, groups by failure pattern, proposes before/after diffs to the agent configuration. Automatically runs `compare` after edits.
+5. **`add-scenario`** — adds scenarios from production failures, edge cases, or gaps. Appends to the frozen `.feature` (additive — self-clears).
+6. **`report`** — scans all eval suites and prints a health dashboard (healthy / degraded / critical / trending-down).
+
+## Eval suite structure
+
+```
+.agents/specs/aced/<category>/<suite-name>/
+  eval.md                 # measurement policy: subject + eval.{layers, judge, trigger}
+  <suite-name>.feature    # the frozen suite — the single eval source
+                          #   boolean scenarios, @rubric (inline rubric) for graded behavior,
+                          #   @trigger Scenario Outline (Examples of query/should_trigger)
+```
+
+Run output is **not** colocated with the spec: it is written under the shared
+`.agents/aced/results/` directory (`<ISO8601>.json`, keyed by target). Keeping it out of the spec
+node is what stops non-deterministic judge output from accumulating beside the frozen suite;
+`init-aced` is responsible for git-ignoring that directory.
+
+`eval.md` is the **measurement policy** — a two-level shape so other measurement kinds slot in as siblings of `eval:`:
+
+```yaml
+subject: plugins/aced/skills/define-skill/SKILL.md
+eval:
+  layers: [trigger, behavior]
+  judge:
+    model: claude-sonnet-4-6
+    default_threshold: 4        # fallback; per-scenario threshold is inline in @rubric
+  trigger:
+    activation_threshold: 0.5
+    runs: 3
+bench:                          # optional: the measured layer (real headless runs)
+  measured: worth               # worth | not-worth; absent bench: = not-worth
+  suite: harbor.nightly         # task set at .agents/aced/bench/<suite>/
+  why: <one line per fit criterion>
+# future (own CRs): a model matrix over the runner family / telemetry (per-run capture)
+```
+
+## Installation
+
+```bash
+npx skills add cyberuni/cyberplace --plugin aced
+```
+
+## Relationship to SDD
+
+ACED is itself built with SDD: specs live in `.agents/specs/aced/<category>/<skill>/`. It uses the same `spec.md` + `.feature` format as the `sdd` plugin, with the eval suite (`eval.md` + `<skill>.feature`) colocated in the same node directory.

package/skills/aced-architect-impl/README.md

@@ -0,0 +1,9 @@
+# aced-architect-impl
+
+The ACED **Architect bar at the impl gate** — whether an agent-configuration artifact is well-formed *as configuration a model loads and executes*. It fills the `architect-impl` governance slot in ACED's squad entry in `.agents/universal-plugin.json`, and **unions onto** `sdd:architect-impl-governance` (the generic structural-fit bar still applies; this adds the agent-config-specific criteria).
+
+Loaded by name, never triggered by users. Two faces read it: the ACED impl-producer reads it forward to self-align while writing, and `aced-impl-judge` reads it backward to grade.
+
+It closes a gap in the production chain. `aced-builder-impl` asks whether the artifact passes its frozen `.feature`; nothing previously asked whether the artifact was usable configuration, so a skill could clear ACED's impl gate while violating every principle in the shipped `skill-design` governance. The criteria here are the gradeable ones: an agent-first body with no mid-workflow links to repository files, no rationale prose, decisions rather than restated best practice, one workflow per artifact with its selection mechanism declared in the `description`, selection kept distinct from the `user-invocable` visibility flag, and no baked-in stack assumptions.
+
+It carries the criteria, not the whole contract. Full depth stays in `cyberplace governance show skill-design` — the repo's sanctioned mechanism for on-demand depth — so there is one source of truth and no 225-line duplicate to drift. That contract is skill-specific; for `subagent`, `command`, and `agents-section` this bar is the entire agent-config shape bar, since no separate shipped contract covers them.

package/skills/aced-architect-impl/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: aced-architect-impl
+description: "Partial Skill: invoke by name only — the ACED Architect bar at the impl gate — whether an agent-configuration artifact is well-formed as configuration. Loaded by the ACED impl-producer to self-align and by the impl-judge to grade. Not triggered by users directly."
+user-invocable: false
+metadata:
+  actor: architect
+  gate: impl
+  compose: union
+---
+
+# ACED Architect-Impl Governance — the agent-config shape bar
+
+The **Architect** bar at the **impl gate**, specialized for agent-configuration artifact-types
+(`skill`, `subagent`, `command`, `agents-section`). It **unions onto**
+`sdd:architect-impl-governance` — the generic structural-fit bar still applies; this adds what makes
+an artifact well-formed *as configuration a model loads and executes*.
+
+The sibling `aced:aced-builder-impl` asks whether the artifact passes its frozen `.feature`. This
+bar asks a question the eval suite cannot: whether the artifact is shaped so a model can act on it.
+An artifact can pass every scenario and still be unusable configuration.
+
+## The bar (per artifact)
+
+- **Agent-first body.** Dense normative rules the agent executes **without opening a linked file
+  first**. A body that defers its own content to a repo path is not self-contained: the model has to
+  stop and fetch before it can act. Optional depth belongs in a closing `## References` — a
+  `governance show` command, an external HTTPS URL, or a sibling file in the same skill folder.
+  **Fail:** a mid-workflow link to another repository file.
+- **No rationale prose.** No `## Why`, `## Rationale`, `## Background`, or `## Context` section, and
+  no causal "because…" explanation in the body. A one-line scope at the top ("Apply when…") is
+  allowed. Rationale lives in an ADR, which outlives the artifact and is read by people rather than
+  loaded into every invocation. **Fail:** a body that argues for its rules instead of stating them.
+- **Decisions over documentation.** The artifact encodes what to decide and how. It does not restate
+  generic best practice, API documentation, or anything the model derives without it. **Fail:**
+  a section that would be equally true in any repository.
+- **One workflow, one artifact.** A single workflow per artifact, with the selection mechanism
+  **declared in the `description`** — matched against a situation, named by a caller, or fired by an
+  event. A name-only artifact carries the description `"By name only"` and nothing else, because the
+  description is the only surface the model matches on and every added word is another handle for a
+  spurious match. **Fail:** a second workflow smuggled in under a heading; identity prose in a
+  name-only description.
+- **Selection is not visibility.** `user-invocable` controls whether the artifact appears in the
+  user's command list, never how it is selected. **Fail:** a bar, judge, or body that reads
+  `user-invocable: false` as "not situationally triggered".
+- **No baked-in opinions.** The artifact detects the user's setup — package manager, monorepo shape,
+  editor, OS paths — at runtime rather than assuming one stack. A genuinely stack-specific artifact
+  says so in its `description`. **Fail:** a hardcoded assumption presented as universal.
+- **An orthogonal axis.** This bar judges a property the eval suite was not optimizing. A finding
+  here is not answerable by adding a scenario.
+
+## Scope across the artifact-types
+
+The criteria above hold for all four types. Where a type has its own additional shape rules, they
+are **not** restated here:
+
+| Artifact-type | Additional contract |
+|---|---|
+| `skill` | `cyberplace governance show skill-design` — frontmatter fields, activation, progressive disclosure, `skill.json`, placement and patterns |
+| `skill` (repo layout) | `cyberplace governance show skill-repo-structure` |
+| `subagent`, `command`, `agents-section` | no separate shipped contract; this bar is the whole agent-config shape bar for them |
+
+## Gaps are `CONTENT_GAP`, never guesses
+
+An artifact whose intended selection mechanism cannot be determined from its `description` returns a
+`CONTENT_GAP`. Do not infer the mechanism from `user-invocable`, from the folder it sits in, or from
+whether it happens to be reachable — inferring is the exact error the selection-is-not-visibility
+criterion exists to catch.
+
+## References
+
+- `cyberplace governance show skill-design` — the full skill authoring contract this bar's criteria
+  are drawn from; read stdout as authoritative.
+- `cyberplace governance show skill-repo-structure` — repository layout for shipped skills.

package/skills/aced-builder-impl/README.md

@@ -0,0 +1,14 @@
+# aced-builder-impl
+
+Internal ACED governance (`user-invocable: false`). The **Builder** actor bar at the **impl gate**,
+specialized for agent-configuration artifact-types — it **unions onto** `sdd:builder-impl-governance`
+and adds how an agent-config subject (which has no deterministic test runner) reaches a per-scenario
+boolean: one scenario→rubric eval per frozen scenario, an explicit N-run policy (trigger vs
+behavior/quality), and a per-dimension `total ≥ threshold` collapse, with the runner (`aced-case-judge`) kept separate
+from the author.
+
+One merged bar loaded by **both** faces — the ACED impl-producer (`define-agent` / `improve`, forward,
+which authors the eval suite) and the cold impl-judge (`aced-impl-judge`, backward, which runs it);
+`producer ≠ judge` holds at the agent level. Bound in `.agents/universal-plugin.json` as the ACED
+squad's `builder-impl` governance; the contract-quality side is the spec gate's `aced-builder-spec`.
+Not triggered by users directly.

package/skills/aced-builder-impl/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: aced-builder-impl
+description: "Partial Skill: invoke by name only — the ACED Builder bar at the impl gate — the frozen .feature conformance criteria. Loaded by the ACED impl-producer to self-align and by the impl-judge to verify. Not triggered by users directly."
+user-invocable: false
+metadata:
+  actor: builder
+  gate: impl
+  compose: union
+---
+
+# ACED Builder-Impl Governance — the eval-suite conformance bar
+
+The **Builder** bar at the **impl gate**, specialized for agent-configuration artifact-types. It
+**unions onto** `sdd:builder-impl-governance` — the generic conformance bar still applies (checks
+derived from the frozen `.feature`, no green-by-tampering); this adds how an *agent-config* subject,
+which has no deterministic test runner, reaches a per-scenario boolean through a scored eval read
+**directly from the frozen `.feature`**. One merged bar loaded by **both** faces — the ACED
+impl-producer (`define-agent` / `improve`, forward, which **builds the subject config**) and the cold
+impl-judge (`aced-impl-judge`, backward, which **runs** the suite). `producer ≠ judge` holds at the
+agent level.
+
+## The bar
+
+- **The eval is the frozen scenario.** The `.feature` is the single eval source: each scenario carries
+  its own eval — a `@rubric` scenario's inline rubric docstring, a `@trigger` `Scenario Outline`'s
+  `Examples`, or a boolean `Then`. The rubric was authored inline by `aced-scenario-writer` and frozen
+  at the spec gate; the impl-judge **runs** it and never free-authors one. A `@rubric` scenario missing
+  its inline rubric block is a `BLOCKER`.
+- **Run policy is explicit — from `eval.md`.** Read the `eval:` block: `@trigger` scenarios run
+  `eval.trigger.runs` against `eval.trigger.activation_threshold` (accuracy); `@behavior`/`@quality`
+  scenarios run N times against the scenario's inline `threshold` (else `eval.judge.default_threshold`),
+  scored by `eval.judge.model`. Defaults when omitted: model claude-sonnet-4-6, default_threshold 4,
+  trigger activation_threshold 0.5, trigger runs 3.
+- **Collapse to a boolean.** A scenario passes when its aggregate **total across the rubric's named
+  dimensions** ≥ `threshold` and no must-not-do was triggered (trigger scenarios: accuracy ≥
+  activation_threshold); `IMPLEMENTATION_PASS` is true only when every frozen scenario passes. Each
+  dimension is scored against its **own** `max` — there is no scale shared across dimensions, and no
+  single collapsed number stands for all of them.
+- **The runner is separate from the author.** Independence comes from the frozen `.feature` anchor and
+  from a runner (`aced-case-judge`) that is not the producer — the producer cannot declare its own pass.
+- **An eval-instrument subject → mutation-sweep-first (inherited).** The **cold-instrument doctrine** on
+  `sdd:builder-impl-governance` applies here unchanged: when the agent-config subject is **itself a
+  measurement or verification instrument** — a rubric, an eval suite, a judge persona, a falsifier — a
+  **mutation sweep is the default verification method** and reading it is supplementary. An author's own
+  eval silently assumes the property under test, so a self-authored ablation over the instrument is not
+  the whole check; sweep it.

package/skills/aced-builder-spec/README.md

@@ -0,0 +1,15 @@
+# aced-builder-spec
+
+Internal ACED governance (`user-invocable: false`). The **Builder** actor bar at the **spec gate**,
+specialized for agent-configuration artifact-types — it **unions onto** `sdd:builder-spec-governance`
+and adds the criteria that make an agent-config `.feature` a complete, simulable contract: concrete
+trigger context per scenario, every rule covered, balanced should-trigger / near-miss cases, ≥3 edge
+guards, pure boolean `Then` steps (no rubric/threshold/score in the suite), and **discrimination** —
+every scenario and every `@rubric` dimension must be able to register a miss against a plausible
+wrong config, with the **config-quoting memorizer** as the default wrong subject and a bar on
+dimensions drawn from the subject's own vocabulary.
+
+One merged bar loaded by **both** faces — the ACED spec-producer (`aced-scenario-writer`, forward)
+and the cold spec-judge (`aced-spec-validator`, backward); `producer ≠ judge` holds at the agent
+level. Bound in `.agents/universal-plugin.json` as the ACED squad's `builder-spec` governance; the
+conformance side is the impl gate's `aced-builder-impl`. Not triggered by users directly.

package/skills/aced-builder-spec/SKILL.md

@@ -0,0 +1,130 @@
+---
+name: aced-builder-spec
+description: "Partial Skill: invoke by name only — the ACED Builder bar at the spec gate — the agent-configuration contract criteria. Loaded by the ACED spec-producer to self-align and by the spec-judge to grade. Not triggered by users directly."
+user-invocable: false
+metadata:
+  actor: builder
+  gate: spec
+  compose: union
+---
+
+# ACED Builder-Spec Governance — the agent-config contract bar
+
+The **Builder** bar at the **spec gate**, specialized for agent-configuration artifact-types
+(`skill`, `subagent`, `command`, `agents-section`). It **unions onto** `sdd:builder-spec-governance`
+— the generic testability/coverage bar still applies; this adds what makes an *agent-config*
+`.feature` a complete, simulable contract. One merged bar loaded by **both** faces — the ACED
+spec-producer (`aced-scenario-writer`) reads it forward, the cold spec-judge (`aced-spec-validator`)
+reads it backward. `producer ≠ judge` holds at the agent level.
+
+## Fit gate — load first
+
+Load **`aced:aced-fit`** and read the subject's declared `**Fit:**` tier **before** applying the
+bar. Two criteria below are **conditional on tier**; a **missing** `**Fit:**` declaration is a
+`CONTENT_GAP` (never default to `strong`); a **wrong-squad** subject is **recused**, not graded
+(`aced:aced-fit`).
+
+## The bar (per scenario, against the `.feature`)
+
+- **Trigger context** *(scenarios that assert firing).* Every firing scenario carries a concrete
+  trigger situation — who the user is, what they said, the state of the tree/files. A firing
+  scenario that uses a vague stand-in ("a file", "some input", "a skill") where the value matters for
+  simulation fails. A `partial`-fit subject has no firing scenarios, so this does not bind.
+- **Rule coverage** *(all tiers).* Every major rule/step in the subject has at least one behavior
+  scenario. A rule with zero scenarios fails.
+- **Validate-section coverage** *(all tiers; when the subject states binding rules on its
+  consumer).* A subject whose body states rules the consuming agent must, must not, always, or
+  never do (a governance's constraint set/checklist/decision table, or a workflow skill's Standard
+  pattern) must carry its own `## Validate` section — one checkable, artifact-state assertion per
+  binding rule, per `improve-skill` Q19 / `define-governance` G9. The suite must include a boolean
+  scenario asserting that section's presence, and — for every assertion mechanical enough to run —
+  that it actually passes against the built artifact. A subject with binding rules and no such
+  scenario fails this bullet; this is not deferred to a lint pass, because a `## Validate` section
+  with no frozen scenario checking it has nothing forcing it to stay accurate as the subject
+  changes. A subject with no binding rules on its consumer (plain ordered steps, or a pure Rubric
+  governance whose scored dimensions already serve this role) is **N/A** — its absence is not a
+  failure.
+- **Trigger balance** *(strong only).* For a **`strong`**-fit subject, both should-trigger scenarios
+  **and near-miss should-not-trigger** scenarios are present (same domain keywords, different intent)
+  — not only obviously-irrelevant negatives; a strong suite with no near-miss fails. For a
+  **`partial`**-fit subject (a mechanical procedure with no activation decision), near-miss is
+  **N/A** — its absence is **not** a failure.
+- **Edge coverage** *(all tiers).* At least three edge-case or must-not-do guard scenarios. A
+  must-not-do guard is a boolean `Then` asserting the agent *does not* do the prohibited action.
+- **Boolean form** *(untagged scenarios).* Every `Then` in an **untagged** scenario is a boolean
+  assertion; a rubric, threshold, or score leaked into an untagged `Then` fails.
+- **Rubric-structure** *(`@rubric` scenarios).* Graded behavior is authored as a `@rubric` scenario
+  with the rubric **inline** (named dimensions + per-dimension `max` + one `threshold` + a collapsing
+  `Then`), per `sdd:suite-format-governance`. A malformed `@rubric` fails before scoring; a well-formed
+  one passes **rubric-structure** (its rubric lingo is the sanctioned form). Structure passing is
+  **not acceptance** — the scenario is still checked for discrimination below. The rubric is
+  spec-owned and frozen with the scenario — the impl-judge *runs* it, it does not author it.
+- **Selection** *(all tiers; every `@rubric` dimension — checked before discrimination).* A `@rubric`
+  is a **compensatory** model: strength on one dimension pays for weakness on another, so a criterion
+  belongs in the sum only if it is **substitutable** — you must accept that trade (per
+  `sdd:suite-format-governance`'s substitutability test). A criterion nobody would trade belongs in a
+  boolean `Then`, not the sum. Agent-config binds **two** further grounds on which a criterion is
+  untradeable **by construction** rather than by trade judgment. They are **disjoint entry points** —
+  a dimension fails selection on either, and neither is a precondition for the other.
+  - **Ground 1 — whole-output span. A dimension whose criterion spans the whole of what the subject
+    produces fails selection, with no boolean twin required.** There is no *rest of the output* left to
+    pay for weakness here, so the compensatory sum has nothing to trade against. The remedy is to author
+    the criterion as **one boolean `@quality` scenario** — never to go hunting for a boolean twin the
+    suite does not have. `@quality` names the **result axis** and `@rubric` is the orthogonal, optional
+    **assertion form** (`sdd:suite-format-governance`, *The tag set*), so a boolean `@quality` scenario
+    is ordinary Form 1 and coins nothing. This is what makes the boolean strictly **stronger** than the
+    dimension: the gate requires every scenario to pass, so a property authored as a boolean cannot be
+    zeroed and bought back on unrelated points, while a dimension can.
+    - **The test is monadic.** Read the **single** criterion against the output: *can you name an
+      attribute of the output this criterion does not touch?* If you can, it is per-attribute and stays
+      a dimension. Sibling dimensions are evidence of how the **output decomposes** — never the object
+      of the comparison. Comparing one candidate dimension against another is the twin-scan #280
+      rejected, on this ground exactly as much as on Ground 2.
+    - **Span is checked before substitutability.** A whole-output criterion never reaches the trade
+      question. So when one is authored **alongside** per-attribute siblings — the shape the
+      persona-voice recurrence actually took — the span ruling governs the spanning criterion and the
+      siblings stay dimensions; the mixed case is not ambiguous, it is ordered.
+    - **A whole-output-*sounding* name is not the test.** `coherence`, `clarity`, `overall_quality`
+      fail only when they genuinely leave no attribute untouched. Apply the naming question to what the
+      dimension **scores**, not to how broadly it is worded.
+  - **Ground 2 — same-object smuggle. A `@rubric` dimension re-grading a property a boolean scenario in
+    the same suite already decides fails selection** — that boolean is an untradeable rule; scoring it
+    as a dimension smuggles it into the compensatory sum. This is the **boolean-smuggling tell**
+    (`design/test-levels.md`, `design/decisions/0002-boundary-vs-surface-more.md`): if ACED rubrics
+    begin restating booleans, the boundary was set too high. The `scenario-writer` keeps such a property
+    **out** of the rubric (authors it as the boolean only, never both); the `spec-validator` fails the
+    dimension.
+  - **On Ground 2 the discriminator is same-object, never same-criterion.** Fail a dimension **on this
+    ground** only when a boolean scenario in the **same suite decides that exact property** — the
+    `only` bounds Ground 2's own test, not selection as a whole, so it never licenses passing a
+    criterion that fails Ground 1. Two `@rubric` dimensions that merely
+    **share a criterion**, with no boolean twin deciding either, do **not** fail selection for sharing
+    it — comparing two dimensions to each other is the twin-scan SDD issue #280 rejected (reconciled in
+    `design/decisions/0002-boundary-vs-surface-more.md`); #280's discrimination verdict (noise, not a
+    hole) and this Selection verdict (a smuggled boolean, out of the sum) are orthogonal reads of one
+    dimension.
+- **Discrimination** *(all tiers; every scenario and every `@rubric` dimension).* Each must be able
+  to **register a miss** — a plausible wrong config must fail it, or score below the dimension's
+  `max` — per the miss test in `sdd:suite-format-governance`, whose **presence / restatement /
+  procedural** anti-patterns and under-threshold floor arithmetic apply unchanged. An agent-config
+  binds it tighter on two counts:
+  - **The memorizer is the default wrong subject.** The subject is a *document the case-judge also
+    reads*, so restatement is the dominant failure mode. Name what a **config-quoting memorizer**
+    scores on each dimension before accepting the rubric.
+  - **Rubric vocabulary is not the subject's vocabulary.** A dimension whose terms are lifted from
+    the config's own prose grades recall of that prose — the memorizer scores it max. Draw the
+    dimension's terms from the behavior under test, not from the artifact that describes it.
+- **Pairwise consistency** *(all tiers; the suite, not a scenario).* No two scenarios sharing a
+  `When` demand opposite verdicts on one constructible snapshot, per `sdd:suite-format-governance`.
+
+## References
+
+- `aced:aced-fit` — the fit classifier this bar loads to make trigger-context / trigger-balance
+  conditional.
+- `aced:improve-skill` (check Q19) / `aced:define-governance` (check G9) — the structural definition
+  of a well-formed `## Validate` section (artifact-state assertions, not restated rules) that
+  Validate-section coverage requires a scenario for.
+- `sdd:suite-format-governance` — the miss test, the wrong-subject table, the three anti-patterns,
+  the substitutability test, and the pairwise-consistency rule this bar specializes.
+- `design/decisions/0002-boundary-vs-surface-more.md`, `design/test-levels.md` — the boolean-smuggling
+  tell and the SDD #280 reconciliation (same-object, not same-criterion) the Selection bullet encodes.

package/skills/aced-fit/README.md

@@ -0,0 +1,21 @@
+# aced-fit
+
+Internal ACED governance (`user-invocable: false`). The **fit classifier** — `strong | partial |
+wrong-squad`, defined as **which of ACED's four eval layers (Structural / Trigger / Behavior /
+Quality) carry real signal** for a subject.
+
+Fit is decided **early** — in explore, by `aced-scenario-writer`, before any scenario is authored —
+and only **enforced** at the gate by `aced-spec-validator`, which reads the declared tier and never
+re-decides it. It makes the spec bar's trigger-context / trigger-balance criteria **conditional on
+tier** (required for `strong`, N/A for `partial`), and **recuses** a `wrong-squad` deterministic
+engine to the SDD-default builder + a script harness instead of forcing the agent-behavior lens onto
+it.
+
+A second, orthogonal axis, **`measured: worth | not-worth`**, says whether real headless runs (the
+measured layer, `eval-run/bench/`) answer a question simulation cannot. It is declared under `bench:`
+in `eval.md` and is opt-in: an absent `bench:` means not-worth and is not a content gap. Dollars
+never decide it.
+
+Loaded by the ACED spec-producer and spec-judge, and by the `bench` skill to re-ask the measured
+criteria for the change in hand. The normative model is `design/fit.md` (ADR 0001 for the tier,
+ADR 0003 for the measured axis). Not triggered by users directly.

package/skills/aced-fit/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: aced-fit
+description: "Partial Skill: invoke by name only — the ACED fit classifier — which of ACED's eval layers carry real signal for a subject. Loaded by the ACED spec-producer and the spec-judge. Not triggered by users directly."
+user-invocable: false
+metadata:
+  type: governance
+---
+
+# ACED Fit Governance — does this config benefit from ACED?
+
+Not every agent configuration benefits from ACED. **Fit** is ACED's self-assessment of a subject,
+**decided early** — in explore by `aced-scenario-writer`, before any scenario is authored — and only
+**enforced** at the gate by `aced-spec-validator` (which reads the declared tier, never re-decides
+it). Fit is a **judgment**, so it lives here as a governance, not a `.mts` engine.
+
+## The diagnostic
+
+**FIT = which of ACED's four eval layers carry real signal for this subject.** The layers:
+**Structural** (fields/format — already covered by `improve-skill`'s `validate.mts` engine), **Trigger** (fires at the
+right times), **Behavior** (follows the steps/rules when invoked), **Quality** (output is good). A
+subject with signal **only** at Structural is not an ACED subject.
+
+## The three tiers
+
+| Tier | The subject… | Layers with signal | ACED applies |
+|---|---|---|---|
+| **strong** | makes a genuine **activation decision** (fuzzy/confusable trigger) **and** has non-deterministic judgment branches | all four | the **full bar** — trigger-context **and** trigger-balance (near-misses) **required** |
+| **partial** | is a real config but **mechanically executes** a predetermined path — no activation choice, behavior still LLM-run/graded | Structural + Behavior (+ Quality) | rule-coverage + edge-coverage + boolean-form; **trigger-balance / near-miss is N/A** (absence is **not** a failure); trigger-context only on scenarios that assert firing |
+| **wrong-squad** | is a **deterministic** script / engine whose output is **assertable, not graded** | Structural only | **recuse** — author **no `.feature`**; the conductor falls back to the SDD-default builder + a script / `node:test` harness (the `sdd:` recuse→fallback seam) |
+
+The `partial ↔ wrong-squad` boundary is **graded-vs-assertable output** (does judging it need an LLM,
+or does a `node:test` assert it), not merely "has a trigger." A subject reached only by name (a
+name-only description) makes no activation decision, so it is never `strong`.
+
+## How each role uses it
+
+- **`aced-scenario-writer` (producer, explore) — decides.** Classify fit **first**; declare it as a
+  `**Fit:** strong | partial` line in the subject's node spec (its `README.md`) `## Use Cases`. Then author to the tier:
+  `strong` → author should-trigger + same-keyword near-miss; `partial` → author behavior/edge/rule,
+  **no fabricated near-miss**; `wrong-squad` → **recuse**, produce nothing, recommend the SDD default.
+- **`aced-spec-validator` (judge, gate) — enforces.** Read the declared tier; apply trigger-context /
+  trigger-balance **only where the tier carries signal**; a **missing** `**Fit:**` declaration is a
+  `CONTENT_GAP` (never default to `strong`); a subject determined wrong-squad is **recused**, not
+  graded.
+
+## The measured axis — a second, orthogonal question
+
+The tier says which **simulated** layers carry signal. A separate axis says whether the **measured**
+layer (real headless runs graded by a shell `check`, `eval-run/bench/`) is worth paying for:
+**`measured: worth | not-worth`**. Never derive one axis from the other — a `strong` skill whose
+change only rewords its trigger is `not-worth`; a `partial` procedure driving multi-step work can be
+`worth`.
+
+`worth` only when **all four** hold:
+
+1. **Work, not words** — the change moves how real work turns out (pass rate, turns, tokens); a
+   trigger-only or wording-only change is `not-worth`.
+2. **Shell-checkable** — a deterministic `check` decides pass/fail; rubric-only outcomes stay
+   simulated.
+3. **A decision hinges on the delta** — merge/revert, calibrate a weight, gate a release.
+4. **Detectable at a run count someone will approve.** Under 4 runs per arm no single task's test
+   can reach p < 0.05; real effects usually need about 10. If the question needs more runs than
+   anyone will approve, it is `not-worth`. The plan's "too few to call" warning reports on this
+   criterion; it does not satisfy it.
+
+**Dollars never decide a result** — cost is recorded and compared, never a gate input; willingness
+to pay bounds only criterion 4.
+
+**Declared** in the subject's `eval.md` under `bench:` (beside `eval:`): `measured`, plus `suite` and
+a `why` of one line per criterion when `worth`. **Absent `bench:` = `not-worth`** — the axis is opt-in, so its absence
+is **not** a `CONTENT_GAP` (unlike the tier's).
+
+- **`aced-scenario-writer` — decides**, in explore, after the tier: declare `bench:` when the
+  subject is `worth`; an explicit `measured: not-worth` is legal to record a considered no; it needs
+  no `suite`, and a `why` is optional; never put the task set in `eval.md`.
+- **`aced-spec-validator` — enforces**: a `bench:` declaring `worth` with no `suite` or no `why` is a
+  `CONTENT_GAP`; it reads `worth`, never re-decides it.
+- **The `bench` skill — re-asks** criteria 1–2 for the change in hand before any plan; the engine's
+  plan checks criterion 4's floor. A `worth` subject can still meet a change that is not.
+
+## Validate
+
+Assertions about **the subject being classified**, run by the producer before handoff and re-run by
+the cold judge against the artifact — never against the producer's account of what it did:
+
+1. The subject's node spec (`README.md`) carries exactly one `**Fit:** strong` or `**Fit:** partial`
+   line; a subject recused as wrong-squad has neither a `**Fit:**` line nor an ACED
+   `eval.md` (its node, if any, was written by the SDD-default chain). *(mechanical)*
+2. A subject declared `strong` does not have a name-only description (one beginning `By name only`
+   or `Partial Skill: invoke by name only`): a subject reached only by name makes no activation
+   decision. *(mechanical)*
+3. If the subject's `eval.md` has a `bench:` key, `bench.measured` is `worth` or `not-worth`.
+   *(mechanical)*
+4. A `bench:` declaring `worth` has a non-empty `bench.suite` and a non-empty `bench.why`.
+   *(mechanical)*
+5. `bench:` holds only `measured`, `suite`, and `why` — never the suite's tasks — and the node
+   spec's frontmatter carries no `bench` or `measured` key. *(mechanical)*
+
+## References
+
+- `design/fit.md` (`.agents/specs/aced/design/fit.md`) — the normative model + ADR 0001 (tier) and
+  ADR 0003 (measured axis).
+- `aced:aced-builder-spec` — the spec bar whose trigger-context / trigger-balance criteria this
+  governance makes conditional.
+- `aced:aced-builder-impl` — the impl bar (which eval layers get evals follows the tier).

package/skills/aced-impl-producer/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: aced-impl-producer
+description: "Partial Skill: invoke by name only — the ACED impl-producer's diagnose-and-refine loop — loaded by define-agent, define-skill, and define-governance, and by the public improve skill for ACED-tracked targets, not user-triggered."
+user-invocable: false
+metadata:
+  actor: producer
+  gate: impl
+---
+
+# ACED Impl-Producer — diagnose and refine
+
+Diagnose failing eval cases and propose targeted edits to the target agent configuration.
+
+## Role: the ACED impl-producer
+
+When the conductor dispatches `define-agent`, `define-skill`, or `define-governance` as a generic builder (`produced-by sdd:automaton`) for the **impl-producer** role (implement mode, against a frozen `.feature`), it builds the **agent configuration** to pass the frozen suite. The **verification is the frozen `.feature` itself** — its inline `@rubric` scenarios and `@trigger` `Examples`, authored by `aced-scenario-writer` at explore and frozen at the spec gate — so the impl-producer does **not** author a separate eval suite. As impl-producer it self-aligns to `sdd:ownership-governance` plus the resolved **builder-impl + architect-impl** bars (the ACED builder-impl is `aced:aced-builder-impl`). When the **impl-judge** (`aced-impl-judge`) reports scenario failures, load this skill to run the diagnose-and-refine loop below. Independence holds because the evals are anchored to the frozen `.feature` and executed by a separate runner (`aced-case-judge`), which is not the producer.
+
+## Load context
+
+Find the target's node in the project spec — `.agents/specs/<project>/…/<node>/` (discovered through
+the SDD spec tree; the node's `eval.md` names the subject) — which holds the frozen `<node>.feature`
+and its colocated `eval.md` (subject + run policy):
+- Read `eval.md` for the `subject` agent configuration path and the `eval:` run policy
+- Read the `subject` agent configuration in full
+- Read the frozen `<node>.feature` (the eval source)
+- Read the most recent result file from `results/` (sort by filename descending, take first)
+
+If no results exist, run `run` first.
+
+## Identify failing scenarios
+
+From the latest results, collect all scenarios where `pass: false`. Read each failing scenario from the frozen `.feature` (its steps and inline `@rubric`).
+
+## Group failures by pattern
+
+Classify each failure into one or more of these patterns:
+
+| Pattern | Signs |
+|---|---|
+| **Trigger false-positive** | Trigger layer case where agent fires when it shouldn't |
+| **Trigger false-negative** | Trigger layer case where agent doesn't fire when it should |
+| **Missing step** | Behavior case where a specific step was skipped |
+| **Ambiguous rule** | Multiple behavior cases fail on the same rule — inconsistent execution |
+| **Conflicting instruction** | Agent followed one rule but violated another in the same agent configuration |
+| **Scope creep** | Agent did more than the agent configuration specifies |
+| **Description mismatch** | Trigger failures suggest the `description:` field doesn't match the body |
+
+Report the pattern groupings before proposing fixes.
+
+## Propose specific edits
+
+For each pattern, propose a concrete change to the agent configuration. Show exact before/after diffs — do not describe changes in prose.
+
+Examples of edit types:
+
+- **Trigger false-positive/negative** → rewrite the `description:` field; add explicit "when NOT to use" section
+- **Missing step** → make the step more prominent; add a concrete example; break it into sub-steps
+- **Ambiguous rule** → replace vague language ("prefer X") with decision rule ("use X when Y, use Z when W")
+- **Conflicting instruction** → add explicit precedence rule or split into separate instructions
+- **Description mismatch** → align `description:` to match what the body actually instructs
+
+## Confirm before applying
+
+Show all proposed edits to the user. Ask for approval before writing any changes.
+
+After user approval, apply edits to the agent configuration. Then automatically run `compare` (before = previous git revision, after = current working tree) to verify the changes improved scores without introducing regressions.
+
+## If no clear fix exists
+
+If failures are caused by inherent non-determinism (high score variance across similar scenarios), recommend:
+1. Adding more specific examples to the agent configuration
+2. Lowering the bar — but a per-scenario `threshold` is **inline in the frozen `.feature`**, so lowering it is a narrowing edit that needs a **re-open + Clearance** at the spec gate, not a casual `eval.md` change (only `eval.judge.default_threshold`, the fallback, lives in `eval.md`)
+3. Splitting the agent configuration into two narrower ones
+
+Do not propose removing scenarios to fix failing evals — that defeats the purpose.