@event4u/agent-config 14.12.0 → 14.13.0

package/dist/agent-src/skills/database/SKILL.md

@@ -113,6 +113,14 @@ SQLite; ORM-agnostic):
 
 ## Gotcha
 
+**MySQL and MariaDB share a query-syntax world. They never share a migration
+one.** Treat them as one engine for writing a `SELECT`, and as two engines for
+everything that changes a schema or reports on a plan: online-DDL semantics,
+lock behavior under `ALTER`, feature availability, and `EXPLAIN` output all
+diverge. Read the engine and its version from the project before making any
+claim in that second group; where the project does not declare one, say the
+engine is unknown rather than assuming.
+
 - Check existing indexes before adding — duplicates waste write performance.
 - Consider multi-tenant implications — queries may need customer DB scoping.
 - `EXPLAIN` output varies between MariaDB and MySQL.

package/dist/agent-src/skills/dependency-upgrade/SKILL.md

@@ -31,6 +31,33 @@ Before upgrading:
 - **Review upgrade guides** — many packages provide migration docs.
 - **Check runtime version requirements** — does the new version need a newer PHP / Node / Python / Go / Rust toolchain?
 
+### 1b. Find where the version is DECLARED, before naming a file to edit
+
+```
+NEVER NAME AN EDIT SITE BEFORE ASKING WHERE THE VERSION IS DECLARED.
+IN A CATALOG WORKSPACE THE MEMBER MANIFEST IS THE WRONG FILE:
+THE VERSION IS ONE ROOT LINE WITH N REFERENTS.
+```
+
+A member `package.json` is the declaration site in an ordinary repository and
+**not** in a workspace using a catalog. There, the member reads `catalog:` and
+the range lives once in the workspace definition — editing the member either
+does nothing or silently diverges from the catalog.
+
+Ask in this order, and stop at the first that answers:
+
+1. **A catalog entry for this dependency** — `pnpm-workspace.yaml` `catalogs:` /
+   `catalog:`, or the equivalent in another manager's workspace definition. If
+   the member's range starts with `catalog:`, this is the edit site. Name the
+   catalog (`default` included) in the guidance, not the member.
+2. **A root-level pin** — `overrides` / `resolutions` / `pnpm.overrides`. A
+   member edit under one of these is overridden at install time.
+3. **The member manifest** — the ordinary case, and only after 1 and 2 are
+   silent.
+
+A repository with no catalog and no root pin behaves exactly as before; this
+step adds a lookup, not a change of default.
+
 ### 2. Plan
 
 Categorize changes needed:

package/dist/agent-src/skills/design-review/SKILL.md

@@ -221,7 +221,7 @@ fields change what a finding *means*:
   all. Under `preserve` a palette or type-family delta is a **defect**; under
   `redesign` it is the point.
 - **`reference_maturity`** decides whether a difference from the reference is a
-  defect. A `wireframe` declares structure, so reproducing its grey boxes is
+  defect. A `wireframe` declares structure, so reproducing its gray boxes is
   over-fidelity, not fidelity.
 
 ```

package/dist/agent-src/skills/doc-coauthoring/SKILL.md

@@ -132,7 +132,7 @@ Verify the doc works for someone without your context.
 * **One question per turn** (Iron Law from `ask-when-uncertain`) — never bundle clarifying + brainstorm + curate prompts in one message.
 * **Never reprint the full doc** during iteration — always use `str-replace-editor`. Reprinting wastes tokens and creates merge drift.
 * **Reader test is not optional** — without it, you ship the version that makes sense to you, not to readers. Skip only on explicit user override.
-* **Sub-agent absence** — `ai-council` may not be configured. Have the manual fresh-Claude fallback ready (Stage 3 step 2).
+* **Subagent absence** — `ai-council` may not be configured. Have the manual fresh-Claude fallback ready (Stage 3 step 2).
 * **Image alt-text** — if the doc embeds images, add alt-text inline; without it, fresh-reader tools can't see them.
 * **Language discipline** — keep the doc body in English (per `language-and-tone`). For verbatim German user phrases or interview quotes, use `DE: … · EN: …` anchor blocks.
 

package/dist/agent-src/skills/existing-ui-audit/SKILL.md

@@ -79,7 +79,23 @@ Design starts from project truth, not generic aesthetic memory.
 | `vue` | `resources/js/components/`, `src/components/`, `pages/` |
 | `plain` | `resources/views/`, plus any `*.html` under `public/` |
 
-Capture each component/template as: `{path, name, kind: page|partial|component|layout, exports?: [props]}`.
+Capture each component/template as:
+`{path, name, kind: component|view|style|page, exports?: [props]}`.
+
+The `kind` set is the one `agent-config ui:audit` actually emits — its single
+definition is `AUDIT_KINDS` in `src/cli/commands/uiAudit.ts`, and a test asserts
+this line against that constant rather than restating it. It read
+`page|partial|component|layout` until 2026-08-26; only two of those four values
+existed in the code, so an artefact written by the command was being read here
+against a contract it did not satisfy.
+
+`partial` and `layout` are not in the set. Neither has an operational definition
+that survives contact with a real tree, and adding a branch for a category
+nobody can test is how the previous mismatch happened.
+
+`view` is the **Blade** classification — `*.blade.php` and `resources/views/`.
+It reads zero in a JavaScript tree by construction, which is not the same as
+unused.
 
 ### 2. Identify the design system
 

package/dist/agent-src/skills/feature-planning/SKILL.md

@@ -121,6 +121,12 @@ Discovery → Exploration → Questions → Architecture → Implementation →
 - Follow chosen architecture from Phase 4.
 - Follow codebase conventions strictly.
 - Track progress via task list or roadmap.
+- **One behavior at a time**: the failing test for that behavior, observed
+  failing, then the minimum code that makes it pass, then the next behavior.
+  Tests are a step of this phase, never a follow-up suggested in Phase 7 —
+  a plan that reaches the summary owing its tests planned test-after.
+  Exceptions are the Do-NOT list in the `test-driven-development` skill,
+  and a skipped cycle is recorded in the decision log rather than passed over.
 
 #### Phase 6: Quality Review
 - Review the implementation for:
@@ -132,7 +138,8 @@ Discovery → Exploration → Questions → Architecture → Implementation →
 
 #### Phase 7: Summary
 - Summarize what was built, key decisions, files modified.
-- Suggest next steps (tests, documentation, follow-up features).
+- Suggest next steps (documentation, follow-up features) — never tests, which
+  Phase 5 already closed per behavior.
 - Update roadmap if applicable.
 
 ## Decision log
@@ -147,7 +154,7 @@ This ensures future developers (and agents) understand the reasoning, not just t
 
 ## Bite-sized task granularity (structural roadmaps only)
 
-When a feature plan's generated roadmap declares `complexity: structural` in its frontmatter, every task bullet must be self-contained and 2–5 minutes of work. Lightweight roadmaps (the default) skip this section — coarse-grained tasks ("Add login endpoint", "Update tests") are correct when the work is well-scoped and low-risk.
+When a feature plan's generated roadmap declares `complexity: structural` in its frontmatter, every task bullet must be self-contained and 2–5 minutes of work. Lightweight roadmaps (the default) skip this section — coarse-grained tasks are correct when the work is well-scoped and low-risk — but coarse means *one behavior*, not one layer: ("Reject login with an unknown email — test, then handler", "Reject login with a wrong password — test, then handler"), never an implementation step followed by an "Update tests" step.
 
 Structural roadmap tasks must include:
 

package/dist/agent-src/skills/frontend-render-security/SKILL.md

@@ -52,6 +52,48 @@ NO SECRET, PRIVILEGED KEY, OR SESSION TOKEN LIVES IN CLIENT CODE OR localStorage
 | `target="_blank"` without `rel="noopener"` | Reverse tabnabbing (CWE-1022) | add `rel="noopener noreferrer"` |
 | Missing CSP; missing alt/label/contrast | No XSS second line of defense; a11y failures | strict CSP (no `unsafe-inline`); alt text, labels, AA contrast |
 
+## The server-composed bootstrap payload
+
+A payload assembled **server-side and serialised into the page** for a client
+island is a data-exposure surface: whatever is put in it is readable by anyone
+who can load the page — no API call, no auth check, view-source. Several
+mainstream frameworks ship their own named channel for exactly this, so the
+pattern is a documented mechanism rather than one project's arrangement.
+
+**Inspect the existing payload before judging any field.** Read what the channel
+already carries and check current call sites for what the client actually
+consumes — a field is only defensible against what the page needs, and a review
+that never opened the payload is a guess. The grep below finds it.
+
+**The per-field question, which is what this section is:**
+
+> Would I return this field from a **public, unauthenticated** endpoint?
+> If not, it does not belong in the payload.
+
+Field classes that recur and are almost always wrong there: internal ids that
+enumerate other users' rows · permission and role structures the client only
+needs a boolean of · feature-flag payloads carrying unreleased product names ·
+anything from an admin-scoped query that was convenient to reuse · a whole
+serialised model where the page needs three of its fields.
+
+**Nothing enforces this, and the split is deliberate.**
+
+| Half | What it does | What it cannot do |
+|---|---|---|
+| the grep below | **locates** a payload a field was added to | tell a privileged field from a public one |
+| this checklist entry | carries the **judgement** | run |
+
+The question is not decidable by any check: a grep over the framework-named
+payload channels cannot read intent. So the deterministic half is discovery,
+advisory and non-blocking, and its whole value is putting the question in front
+of a reader who would otherwise never see it. `enforced_by: none` is the honest
+field here — this section refuses nothing.
+
+**What may NOT be encoded.** The particular channel any one repository uses.
+What is encoded is the question and the framework-named channels; a concrete
+in-house payload shape would be one repository's implementation shipped as
+guidance.
+
 ## Backstop greps
 
 Run before committing frontend changes; each should return zero (or every hit is read and justified):
@@ -66,6 +108,8 @@ rg -n "origin:\s*['\"]\*['\"]|Access-Control-Allow-Origin.*\*"
 rg -n "addEventListener\(\s*['\"]message['\"]"   # then confirm each checks event.origin
 # Unhardened external links
 rg -n 'target=["'\'']_blank["'\'']'   # then confirm rel="noopener" present
+# Server-composed bootstrap payload — LOCATES it; the per-field judgement is yours
+rg -n '__NEXT_DATA__|__NUXT__|window\.__INITIAL_STATE__|@json\(|json_encode\([^)]*\)\s*\)?\s*</script>|dehydratedState'
 ```
 
 ## Output format

package/dist/agent-src/skills/git-workflow/SKILL.md

@@ -9,7 +9,7 @@ scope:
 execution:
   type: assisted
   handler: internal
-  allowed_tools: ["github"]
+  allowed_tools: ["Bash(git:*)", "Bash(gh:*)"]
 workspaces:
   - engineering
 packs:

package/dist/agent-src/skills/js-library-packaging/scripts/check_package_surface.ts

@@ -143,20 +143,54 @@ export const checkPackage = (root: string): SurfaceReport => {
     };
     if (exportsField !== undefined) walkConditions(exportsField, 'exports.');
 
-    // (d) — a `workspace:` range only resolves inside the workspace. Published with no
+    // (d) — a range that only resolves INSIDE the workspace. Published with no
     // `private: true` and no publishConfig, the consumer's install fails on a protocol
     // their registry has never heard of.
-    const allDeps = { ...deps, ...asRecord(manifest['devDependencies']), ...peers };
-    const workspaceRanges = Object.entries(allDeps).filter(([, v]) => typeof v === 'string' && v.startsWith('workspace:'));
+    //
+    // `catalog:` was added 2026-08-26 (road-to-internal-estate-fit 4.1) and it is the
+    // same defect, not an adjacent one: pnpm's catalog protocol resolves against the
+    // workspace's catalog definition and means nothing to a registry. It had been
+    // passing as an ordinary registry range, so the finding did not fire where it
+    // should. One predicate, two prefixes — the finding code and its reason carry over
+    // unchanged, which is why this is not a second finding type.
+    const UNPUBLISHABLE_RANGE_PREFIXES = ['workspace:', 'catalog:'] as const;
+    // Each dependency map is scanned SEPARATELY rather than spread into one
+    // object. The previous `{ ...deps, ...devDeps, ...peers }` merge let a later
+    // map SHADOW an earlier one for the same package name: a `workspace:` range
+    // in `dependencies` for a package that also appears in `peerDependencies`
+    // with a registry range was invisible, because the peer value won the spread.
+    // Found 2026-08-26 by a `catalog:` fixture for a name the test manifest also
+    // lists as a peer; fixed with 4.1 rather than noted, because it is the same
+    // predicate and the same few lines.
+    const workspaceRanges: [string, unknown][] = [
+        deps,
+        asRecord(manifest['devDependencies']),
+        peers,
+    ].flatMap((m) =>
+        Object.entries(m).filter(
+            ([, v]) =>
+                typeof v === 'string' &&
+                UNPUBLISHABLE_RANGE_PREFIXES.some((pre) => v.startsWith(pre)),
+        ),
+    );
     if (
         workspaceRanges.length > 0 &&
         manifest['private'] !== true &&
         manifest['publishConfig'] === undefined
     ) {
+        const prefixes = [
+            ...new Set(
+                workspaceRanges.map(
+                    ([, v]) =>
+                        UNPUBLISHABLE_RANGE_PREFIXES.find((pre) => (v as string).startsWith(pre)) ??
+                        '',
+                ),
+            ),
+        ].sort();
         findings.push({
             code: 'workspace-range-publishable',
             severity: 'warn',
-            message: `${String(workspaceRanges.length)} \`workspace:\` range(s) in a package that is neither private nor carrying publishConfig — the protocol does not resolve outside the workspace`,
+            message: `${String(workspaceRanges.length)} workspace-local range(s) (${prefixes.join(', ')}) in a package that is neither private nor carrying publishConfig — the protocol does not resolve outside the workspace`,
         });
     }
 

package/dist/agent-src/skills/judge-artifact-completeness/rubrics/ticket-quality-score.json

@@ -18,8 +18,8 @@
       "name": "Acceptance criteria",
       "cross_cutting": false,
       "weight": 3,
-      "criterion": "Acceptance criteria are written as verifiable Given-When-Then or numbered checklist items, not as task descriptions. Each criterion is independently testable. An implementer can write a test before touching code.",
-      "gap_signal": "AC section missing; or AC items are task descriptions ('implement the API') rather than verifiable outcomes ('returns 200 with a body matching the schema')."
+      "criterion": "Acceptance criteria are independently testable outcomes, not task descriptions — an implementer can write a test before touching code. Whether they are owed in Given-When-Then form is decided by the observable-behavior test in `src/skills/test-case-discovery/SKILL.md` § Does this change owe an executable behavior contract?, not asserted here: most tickets owe verifiable checklist items, and only a change with an audience outside the code owes a behavior contract. Where one is owed, that section's anti-script rule applies — a criterion naming a selector, a timeout or a keystroke scores as a gap, however well-formed its Given-When-Then.",
+      "gap_signal": "AC section missing; or AC items are task descriptions ('implement the API') rather than verifiable outcomes ('returns 200 with a body matching the schema'); or a Given-When-Then criterion scripts the interface ('When I click #submit') instead of stating the rule."
     },
     {
       "id": "dor_readiness",

package/dist/agent-src/skills/laravel/SKILL.md

@@ -33,6 +33,41 @@ Use this skill for all Laravel-specific code generation and editing tasks, espec
 
 This skill extends the base `php-coder` skill and applies Laravel conventions on top of the project's general PHP rules.
 
+## When NOT to use — components without the framework
+
+```
+A DEPENDENCY PROVES A LIBRARY IS AVAILABLE. ONLY THE ENTRY POINT AND THE
+ROUTER PROVE WHICH APPLICATION SHAPE IS RUNNING.
+`illuminate/*` PACKAGES WITH NO SKELETON MARKER IS A THIRD STATE, AND THIS SKILL
+DOES NOT APPLY TO IT.
+```
+
+Laravel ships its ORM, container, collections and HTTP layer as
+independently installable packages, usable with no framework present — a
+published distribution model, not one consumer's arrangement. An application
+built that way has a **custom entry point and a custom router**. Routing it here
+offers a CLI that does not exist, a request-validation primitive that is not
+wired, and a routes file that was never there: every suggestion confidently
+wrong, and the reason visible only from the entry point.
+
+**The probe set, and its cost.** A fixed set of filesystem existence checks plus
+one manifest read — no directory walk, no content scan, and never re-derived per
+session. Any ONE marker present means the framework is real:
+
+| Probe | Meaning |
+|---|---|
+| `artisan` | the console entry point the skeleton writes |
+| `config/app.php` | the skeleton's bootstrap config |
+| `bootstrap/app.php` | the application bootstrap |
+
+`illuminate/*` in `composer.json` with **none** of those markers is
+*components-without-the-framework*. Say so and route away from this skill rather
+than answering as though the framework were there.
+
+Implemented deterministically in `src/install/detect_php_shape.ts`
+(`detectPhpShape`), whose `PROBE_PATHS` is this table and whose verdict names
+what a wrong route would have offered.
+
 ## Procedure: Write Laravel code
 
 → **First apply the `php-coder` skill** — it handles project docs, module docs, patterns, and quality tools.

package/dist/agent-src/skills/laravel-migration/SKILL.md

@@ -36,7 +36,8 @@ Use this skill when the user asks to create a database migration, add a column,
 - Use `decimal` for money — never `float`.
 - Add indexes for columns used in WHERE clauses and JOINs.
 - Match existing column naming patterns in the same table or domain.
-- Always include a reversible `down()` method.
+- Declare recovery: a reversible `down()`, or a roll-forward plan in the file
+  (see § The recovery contract below). Silence is the violation.
 
 ## Laravel projects
 
@@ -73,7 +74,10 @@ return new class extends Migration {
             $table->foreign('customer_id')
                 ->references('id')
                 ->on('customers')
-                ->onDelete('cascade');
+                // Choose the referential action; never inherit it from a
+                // template. See "Referential action is a decision" below.
+                ->onDelete('cascade'); // cascade: rows here are expendable
+                                       // WITHOUT their customer
 
             $table->index('is_active');
         });
@@ -143,6 +147,54 @@ php artisan migrate --env=testing             # testing
 1. Migration file with up() and down() methods
 2. Model updates if columns or relationships changed
 
+### The recovery contract — one obligation, two branches
+
+Every migration declares **one** of these, and silence is the violation:
+
+1. a `down()` that restores the prior state; **or**
+2. a **roll-forward recovery plan, written in the migration file itself**, for
+   the cases where restoration is genuinely impossible — a completed
+   destructive backfill, a dropped column whose data is gone.
+
+The second branch is not a lighter obligation. A migration taking it records, in
+its own file comments, all three of:
+
+1. **why restoration is impossible**, with the evidence — the data was checked
+   and is unrecoverable, not assumed to be;
+2. **the ordered recovery procedure** — the steps, the inputs each needs, and
+   the criteria that say recovery succeeded;
+3. **the responsible recovery owner**.
+
+Vague intent or missing detail is the violation. The plan lives in the migration
+file and lands in the same diff, because a plan documented "later" somewhere else
+is a plan nobody can review at the moment it matters.
+
+## Referential action is a decision
+
+The template above labels its `onDelete('cascade')` as **one branch**, not a
+default. Copying it unchanged is how a delete of one customer silently removes
+records that had independent value.
+
+| The child row, without its parent, is | Action | What happens |
+|---|---|---|
+| **expendable** — it only means something as part of the parent | `cascade` | deleted with the parent |
+| **self-valued** — it is a record in its own right (an invoice, an audit row, a payment) | `restrict` (or `no action`) | the parent delete FAILS until the child is dealt with |
+| **survivable** — it outlives the parent with the link removed | `set null` | the column is nulled; requires a nullable column |
+
+Two consequences worth stating because they are the ones missed:
+
+- `restrict` is the safe default for anything a finance, audit, or legal reader
+  would expect to still exist. A failed delete is a conversation; a cascaded
+  delete is a recovery.
+- `set null` needs the foreign-key column to be nullable, and it needs the
+  application to handle the orphan state. Choosing it without both is choosing a
+  constraint error later.
+
+Soft deletes do **not** interact with this: `onDelete` fires on a real `DELETE`,
+so a soft-deleting parent never triggers it. If the model soft-deletes, the
+referential action describes what happens on a force-delete or a purge, and that
+is the case to decide against.
+
 ## Gotcha
 
 - Always check if the table/column already exists before creating the migration — the model doesn't always check.
@@ -155,7 +207,9 @@ php artisan migrate --env=testing             # testing
 - Do NOT create migrations without specifying the correct connection when multiple databases exist.
 - Do NOT create tables without checking the project's naming conventions (prefixes, casing).
 - Do NOT use raw SQL in migrations when Schema builder works.
-- Do NOT forget to make migrations reversible (down method).
+- Do NOT leave recovery undeclared — ship a `down()` that restores the prior
+  state, or the three-part roll-forward plan in the migration file. Neither is
+  optional; choosing between them is.
 - Do NOT use `float` for money — use `decimal`.
 - Do NOT forget indexes on foreign keys and frequently filtered columns.
 

package/dist/agent-src/skills/monorepo-workspace/SKILL.md

@@ -57,6 +57,24 @@ In precedence order, and report which one answered:
 Globs are globs: `packages/*` means every direct child carrying a manifest, not
 every directory.
 
+### 2b. Catalogs — the version is declared once, not per member
+
+When the workspace defines a **catalog**, a member's `catalog:` range is a
+REFERENCE, not a declaration. Report the catalog as the version's home:
+
+- A member range starting `catalog:` (bare, or `catalog:<name>`) resolves
+  against the workspace catalog definition. It does not resolve outside the
+  workspace at all — treat it exactly as `workspace:` for publishability.
+- **An upgrade edits the catalog, not the member.** Editing a member that reads
+  `catalog:` is either a no-op or a silent divergence from the catalog, and the
+  catalog exists precisely so the version has one home.
+- **A member carrying a version LITERAL for a dependency the catalog also
+  declares is reported, not gated** — see § Do NOT. Name the member, the
+  dependency, the literal range, the catalog name and the catalog range. Where
+  several catalogs declare the same dependency, list every candidate rather than
+  inventing an applicable one; nothing in the workspace definition says which
+  the literal intended to follow.
+
 ### 3. Task runner — ask the runner, do not read its config
 
 When a runner is present, its own listing is the source of truth, because a
@@ -133,6 +151,14 @@ When the runner was absent, the last line reads
 
 ## Do NOT
 
+- **Do NOT gate on a member version literal.** Whether a catalog repository
+  permits selective literals is that repository's convention, not this suite's
+  to impose. Report it as a structural observation — *"member literal overlaps
+  catalog entry"*, never *"invalid"* — and let the reader decide. An exact
+  mismatch between the literal and the catalog range is reported at higher
+  severity, and still does not gate.
+
+
 - Read `project.json` by hand to enumerate Nx projects — `nx show projects` is
   the source of truth and includes inferred targets.
 - Install `turbo` or `nx` to answer a question. They are the consumer's

package/dist/agent-src/skills/playbook-authoring/SKILL.md

@@ -112,6 +112,33 @@ The derivation therefore unwraps a thin wrapper and records what it points at, a
   confirm, and the file says which id failed. Downgrading is the honest outcome; writing
   the stronger claim and hoping is the failure this skill exists to prevent.
 
+## A confirmed canonical answer is a playbook — including the awkward one
+
+A repository's answer to *"where does new code of this kind go"* is a playbook
+once it has been **confirmed**, graded like any other: `configured` when every
+cited id resolved, `observed` when one did not.
+
+**The awkward case is the one worth writing down.** A public surface version and
+an **implementation generation** are independent axes — a `v1` controller can
+carry the current internal architecture while a `v2` one is half-migrated and
+abandoned. So the canonical answer for a scope is frequently *"the
+older-looking lane"*, and that is exactly the answer nobody records because it
+reads as a mistake. **ADR-248** holds the evidence order that produces it: a live
+decision record, then an executable architecture test, then a shared abstraction
+in maintained code, then current tests and contracts, then several recent
+analogous implementations, then migration docs, then git history, and **names and
+paths last**.
+
+Two bounds, both deliberate:
+
+- **Per scope, never per artifact type.** A repository may legitimately have two
+  right answers in two modules. There is no single global exemplar, and a
+  playbook claiming one is over-reaching its own `scope`.
+- **No second contract.** This is the ADR-244 playbook class unchanged — not a
+  conventions map, not a canonicality registry. A confirmed answer is a
+  playbook; an unconfirmed one is a hypothesis and belongs in the analysis that
+  produced it.
+
 ## Output format
 
 1. One playbook per file in the playbook home, frontmatter first: `task`, `scope`, `grade`,
@@ -156,7 +183,7 @@ The derivation therefore unwraps a thin wrapper and records what it points at, a
 
 ## See also
 
-- [ADR-244](../../../docs/decisions/ADR-244-playbook-is-a-sixth-context-type.md) — the artefact class, its grades, its home, and the two deferred kinds.
+- [ADR-244](../../../docs/decisions/ADR-244-playbook-is-a-sixth-context-type.md) — the artifact class, its grades, its home, and the two deferred kinds.
 - [`standards-from-config`](../standards-from-config/SKILL.md) — the Class-A rule this applies to procedure rather than to style.
 - [`context-document`](../context-document/SKILL.md) — the contexts machinery a playbook reuses as its sixth type.
 - [`command-writing`](../command-writing/SKILL.md) — the numbered-step shape the body follows.

package/dist/agent-src/skills/react-shadcn-ui/SKILL.md

@@ -24,7 +24,7 @@ execution:
   handler: shell
   safety_mode: strict
   allowed_tools:
-    - npx
+    - Bash(npx:*)
 ---
 
 # react-shadcn-ui

package/dist/agent-src/skills/skill-writing/references/procedure.md

@@ -258,7 +258,7 @@ rubric:
 ```
 
 `contains` / `file_exists` grade deterministically. `rubric` items grade
-via a fresh sub-agent reading the output against the criterion — keep
+via a fresh subagent reading the output against the criterion — keep
 each criterion to one falsifiable sentence.
 
 **Loop** (orchestrated by `scripts/run_skill_evals.ts`):
@@ -266,14 +266,14 @@ each criterion to one falsifiable sentence.
 1. **Scaffold** — `./scripts-run src/scripts/run_skill_evals scaffold {skill}`
    creates `runs/{timestamp}-{baseline,with-skill}/` and seeds each
    scenario's `meta.json`.
-2. **Baseline run** — spawn one sub-agent per scenario **without** the
+2. **Baseline run** — spawn one subagent per scenario **without** the
    skill loaded. Capture stdout + any artifacts into
    `runs/{timestamp}-baseline/{scenario-id}/`.
-3. **With-skill run** — same scenarios, same sub-agent harness, **with**
+3. **With-skill run** — same scenarios, same subagent harness, **with**
    the skill loaded. Capture into `runs/{timestamp}-with-skill/{scenario-id}/`.
 4. **Grade** — for each scenario, write a `grade.json` file with
    per-assertion pass/fail. Deterministic assertions auto-grade;
-   rubric assertions need a grader sub-agent.
+   rubric assertions need a grader subagent.
 5. **Aggregate** — `./scripts-run src/scripts/run_skill_evals aggregate {skill}
    --run {timestamp}` produces `runs/{timestamp}-benchmark.json` with
    pass-rate, timing, token deltas baseline-vs-with-skill.
@@ -281,7 +281,7 @@ each criterion to one falsifiable sentence.
    --run {timestamp}` prints the diff. Iterate on the skill body
    until `with-skill` outperforms `baseline` on every scenario.
 
-The script ships with sub-agent spawning **stubbed** — the orchestration
+The script ships with subagent spawning **stubbed** — the orchestration
 layer is per-environment (Claude Code, Augment, council). Implement
 the spawn function once for your environment, the rest of the loop
 (aggregate / report / scaffold) works out of the box.

package/dist/agent-src/skills/sql-writing/SKILL.md

@@ -30,7 +30,7 @@ Do NOT use when:
 
 1. **Inspect call site & choose approach** — identify every dynamic value flowing into the query, then pick: query builder when possible. Raw SQL only when query builder can't express the query.
 2. **Parameterize** — Every variable must use `?` binding or named `:param`. Never interpolate PHP variables into SQL strings.
-3. **Use MariaDB syntax** — Not PostgreSQL or MSSQL. Check `php/sql.md` for MariaDB-specific patterns.
+3. **Read the engine, then choose the syntax** — check, in order: the project's DB config (`config/database.php` default connection, `DB_CONNECTION`), a `docker-compose.yml` service image, a migration using engine-specific syntax. MySQL and MariaDB share the query-syntax world this skill writes in; PostgreSQL and MSSQL do not. **If none of those declare an engine, say so and ask — do not assume one.** A query written for the wrong engine passes review and fails in production.
 4. **Verify** — Run EXPLAIN on complex queries. Check that no PHP interpolation (`"$var"`, `'{$var}'`) appears in SQL.
 
 ```
@@ -66,6 +66,12 @@ DB::select("SELECT * FROM users WHERE email = '{$email}'");
 
 ## Gotcha
 
+**MySQL and MariaDB share a query-syntax world. They never share a migration
+one.** Same principle as `database`: one engine for writing a `SELECT`, two for
+online-DDL semantics, lock behavior under `ALTER`, feature availability and
+`EXPLAIN` output. Never carry a claim from the second group across the two
+without naming the engine and version it was measured on.
+
 - MariaDB and MySQL have subtle syntax differences.
 - The model writes `$variable` in SQL strings instead of `?` placeholders.
 - `GROUP BY` with `ONLY_FULL_GROUP_BY` requires all non-aggregated columns.

package/dist/agent-src/skills/standards-from-config/SKILL.md

@@ -50,20 +50,43 @@ found", do not fabricate one).
    - Python: `pyproject.toml` / `ruff.toml` (`[tool.ruff]`, `[tool.black]`),
      `setup.cfg`.
    - Ruby: `.rubocop.yml`. Go: `gofmt`/`golangci.yml`.
-2. **Derive as pointer + digest, never a flattened claim.** Each standard is one
+2. **Follow the chain before you digest, and pick the config NEAREST the edit.**
+   Read literally — one file, one parse — this procedure returns a null on a
+   repository whose root config is a single `extends`. A fourteen-line linter
+   config whose only load-bearing line points into a package in the same
+   workspace is not a project without standards; it is a project whose standards
+   are one hop away, and "no enforced standard found" there is a false negative
+   that reads exactly like a true one. `extends` is specified in TypeScript,
+   ESLint, Biome and Stylelint; `includes` plays the same role in PHPStan and
+   Rector; `workspace:` is documented in npm, yarn, pnpm and bun.
+   - **Precedence is nearest-first, and it is not a preference.** The config in
+     the edited path's own directory governs, then its parent, up to the
+     repository root. A per-package `tsconfig.json`, `.eslintrc`, `.env` or
+     deployment manifest is the one that package's build reads; a root file it
+     does not extend has no effect on it. Reading the root config for an edit
+     inside a package that carries its own is a **wrong** answer, not a coarse
+     one. Report the outranked root candidate too, so the precedence is visible.
+   - **An unresolvable hop is a named gap with a PARTIAL digest, never an
+     absence.** Say which hop failed and why. A partial digest naming its gap is
+     usable; a null that reads as "no standards" is a lie.
+   - **A hop that leaves the repository is labelled `external` and excluded from
+     the digest.** Presenting a third-party preset as the project's own standard
+     is worse than reporting nothing — the reader cannot tell which rules the
+     project chose. Report it with its path; do not merge it.
+3. **Derive as pointer + digest, never a flattened claim.** Each standard is one
    line: the **value**, the **config file it came from**, and the **scope** it
    applies to. Write `ruff.toml → line-length = 88 (scope: src/**/*.py)`, NOT
    "the project uses line length 88". The pointer makes the claim re-checkable
    and the next agent can open the config to confirm.
-3. **Preserve scope; surface conflicts, never flatten them.** If two configs (or
+4. **Preserve scope; surface conflicts, never flatten them.** If two configs (or
    an inline / per-directory override) give two values, emit **two pointers with
    two values + their scopes** — never one ambiguous merged claim. A visible
    conflict is correct; a hidden flattened guess is the failure mode.
-4. **Stamp staleness.** Record each source's `config_mtime` (or content hash).
+5. **Stamp staleness.** Record each source's `config_mtime` (or content hash).
    The digest is stale when the config file's mtime/hash changes → re-derive. No
    human gate is needed (Class A is deterministic) — the digest is **regenerated
    from the config, never hand-edited**.
-5. **Persist** as a Class-A context card under `agents/settings/contexts/` (see
+6. **Persist** as a Class-A context card under `agents/settings/contexts/` (see
    Output format). Class A is high-trust *because* config-derived — it is read
    for heuristics only and never bypasses a fresh structural read (the v1↔v2
    isolation contract in `evidence-discipline`).

package/dist/agent-src/skills/supply-chain-intake/SKILL.md

@@ -51,18 +51,25 @@ PIN IT, LOCK IT, CVE-SCAN IT. NEVER PIPE A REMOTE SCRIPT STRAIGHT TO A SHELL.
    ```
    Non-existent, brand-new (published days ago), or near-zero-download → **stop**, treat as hallucination/slopsquat.
 2. **Typo-adjacency** — is the name within 1–2 chars of a far-more-popular package (`python-dateutil` vs `dateutil`, `lodahs` vs `lodash`)? If so, you probably want the popular one — confirm before installing.
-3. **Version safety** — the model's version pin may predate a CVE fix (training-cutoff reintroduction). Take the current patched release, then scan:
+3. **Version source — look it up BEFORE you write a version, and report which outcome you got.** This is a precondition of step 4, not a note on it. Two outcomes, with opposite handling, and only the first is forbidden:
+   - **Invention** — writing a version string that **no source in the repository produced**. Always forbidden. A version that appeared from nowhere is unverifiable by anyone downstream, including you an hour later.
+   - **Lookup failure** — having searched the **declared version sources** and found none. Those sources are per ecosystem: a catalogue or a `workspace:` protocol entry, an existing manifest in the tree (`package.json`, `composer.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`), and the lockfile. This is **not** a violation. Resolving it from the registry or from the user is the correct move; report it as *unresolved-then-resolved* with the source named.
+
+   **Silence is the failure, never the fallback.** Producing a version with no source and no report is the thing the rule forbids; reporting an unresolved lookup is the thing it asks for.
+
+   A manifest that already expresses a version through a protocol — `workspace:*`, a catalogue reference — is **left as it is**. Rewriting it to a literal discards the mechanism the repository chose and pins a value the workspace was resolving for you. `workspace:` is documented in npm, yarn, pnpm and bun; catalogued versions are a documented feature of pnpm and bun.
+4. **Version safety** — the model's version pin may predate a CVE fix (training-cutoff reintroduction). Take the current patched release, then scan:
    ```bash
    npm audit           # block on high/critical
    pip-audit
    osv-scanner -r .
    ```
-4. **Pin + lock** — install exact + commit the lockfile; reject floating ranges (`^`, `latest`, no lockfile) on production deps.
+5. **Pin + lock** — install exact + commit the lockfile; reject floating ranges (`^`, `latest`, no lockfile) on production deps.
    ```bash
    npm install --save-exact <pkg> && git add package-lock.json
    ```
-5. **License** — confirm the license is compatible with the project's declared license before it lands.
-6. **No pipe-to-shell** — never `curl … | bash` an install; download → inspect → execute over pinned HTTPS, or surface it to the user for confirmation.
+6. **License** — confirm the license is compatible with the project's declared license before it lands.
+7. **No pipe-to-shell** — never `curl … | bash` an install; download → inspect → execute over pinned HTTPS, or surface it to the user for confirmation.
 
 ## MCP-server intake — the dependency gate plus two extra checks