@nurix/etna 0.18.0 → 0.18.2

package/data/harnesses/code/skills/boundary/SKILL.md

@@ -7,45 +7,21 @@ description: Boundary diagnostic for implementation plans. Given a plan file, re
 
 You diagnose whether a plan's changes would break an application boundary.
 
-A boundary is a contract between two pieces of code (or code and infra) that
-share an assumption with **no compile-time link** between them: the column a raw
-SQL string names, the JSON envelope a client unwraps, the event string a
-dispatcher parses, the env var a deploy script writes. Changing one side ships
-green and breaks the other silently. Your job is to find those edges in the
-plan's path *before* execution.
-
-[`references/boundary-taxonomy.md`](references/boundary-taxonomy.md) is the
-catalog of boundary types (~170 across persistence, wire/API, frontend,
-auth/tenancy, async/messaging, config/build, runtime/infra), with per-type
-severities and safe-change checklists. Read it first — it tells you what to
-look for; the code tells you what exists.
+A boundary is a contract between two pieces of code (or code and infra) that share an assumption with **no compile-time link** between them: the column a raw SQL string names, the JSON envelope a client unwraps, the event string a dispatcher parses, the env var a deploy script writes. Changing one side ships green and breaks the other silently. Your job is to find those edges in the plan's path _before_ execution.
+
+[`references/boundary-taxonomy.md`](references/boundary-taxonomy.md) is the catalog of boundary types (~170 across persistence, wire/API, frontend, auth/tenancy, async/messaging, config/build, runtime/infra), with per-type severities and safe-change checklists. Read it first — it tells you what to look for; the code tells you what exists.
 
 ## Run
 
-**Input:** a plan path (given, or the newest in `docs/history/plans/`) — or a
-diff / named code area for non-plan work. Everything below is identical either
-way; a diff's hunks stand in for the plan's steps.
-
-1. **Build the touch list.** Parse the plan's Proposed Changes: files to be
-   created or modified, entities/state added or changed, API changes, anything
-   the author flags as a cross-module contract. Note missing subsections.
-
-2. **Identify the boundaries in the touched code.** Read each touched file (and
-   its immediate imports). Against the taxonomy, list the contracts this code
-   participates in — the schema it queries, the envelope it emits, the events
-   it publishes or parses, the auth checks it sits behind, the env it reads.
-
-3. **Trace the other side.** A boundary has two sides; the danger lives on the
-   one the plan *doesn't* mention. For each contract, grep the shared name or
-   shape across the repo — the column name in other SQL strings, the response
-   field in client unwrappers, the event kind in subscribers, the route in
-   fetch calls and scripts, the env key in deploy tooling. Record consumers as
-   `file:line`.
-
-4. **Judge each intersection.** Does the planned change alter a shape a traced
-   consumer depends on, break an invariant the code establishes (append-only
-   vocabularies, idempotency keys, fail-closed checks, ordering guarantees), or
-   add a new cross-module edge? Severity:
+**Input:** a plan path (given, or the newest in `docs/history/plans/`) — or a diff / named code area for non-plan work. Everything below is identical either way; a diff's hunks stand in for the plan's steps.
+
+1. **Build the touch list.** Parse the plan's Proposed Changes: files to be created or modified, entities/state added or changed, API changes, anything the author flags as a cross-module contract. Note missing subsections.
+
+2. **Identify the boundaries in the touched code.** Read each touched file (and its immediate imports). Against the taxonomy, list the contracts this code participates in — the schema it queries, the envelope it emits, the events it publishes or parses, the auth checks it sits behind, the env it reads.
+
+3. **Trace the other side.** A boundary has two sides; the danger lives on the one the plan _doesn't_ mention. For each contract, grep the shared name or shape across the repo — the column name in other SQL strings, the response field in client unwrappers, the event kind in subscribers, the route in fetch calls and scripts, the env key in deploy tooling. Record consumers as `file:line`.
+
+4. **Judge each intersection.** Does the planned change alter a shape a traced consumer depends on, break an invariant the code establishes (append-only vocabularies, idempotency keys, fail-closed checks, ordering guarantees), or add a new cross-module edge? Severity:
    - **CRITICAL** — can corrupt persisted data, or open an auth/money path.
    - **HIGH** — silent cross-module breakage that would ship green.
    - **MEDIUM** — drift-prone coupling (string-matched, duplicated constants).
@@ -67,10 +43,7 @@ way; a diff's hunks stand in for the plan's steps.
 
 ## Rules
 
-- **Read-only.** You never edit the plan, the code, or any doc. The user folds
-  your amendments into the plan.
-- **Verify in source.** Never flag from plan text alone — read both sides of
-  every boundary you report, and cite both as `file:line`.
-- **No consumer, no finding.** An intersection with no traced other side isn't
-  a violation; at most note it as a new edge the plan introduces.
+- **Read-only.** You never edit the plan, the code, or any doc. The user folds your amendments into the plan.
+- **Verify in source.** Never flag from plan text alone — read both sides of every boundary you report, and cite both as `file:line`.
+- **No consumer, no finding.** An intersection with no traced other side isn't a violation; at most note it as a new edge the plan introduces.
 - **A clean report is valid.** Zero violations means say so — don't pad.