@nurix/etna 0.19.65 → 0.19.67

package/data/harnesses/apollo/skills/test/SKILL.md

@@ -1,104 +0,0 @@
----
-name: test
-description: Test Runner using Chrome DevTools Protocol (CDP). Run UI tests with Claude-in-Chrome browser automation. Triggers include: "run my tests", "run the test suite", "execute tests", "test this code", "check if tests pass".
-argument-hint: [test-name]
----
-
-# Test Runner (CDP)
-
-Run UI tests using Claude-in-Chrome browser automation.
-
-## Prerequisites
-
-Complete these steps before executing test assertions:
-
-### 1. Load Credentials
-
-Read `tests/.env` for: `TEST_USER_EMAIL`, `TEST_USER_PASSWORD`, `TEST_BASE_URL`, `TEST_APP_ID`
-
-- `TEST_USER_EMAIL` / `TEST_USER_PASSWORD`: credentials used to log in during browser setup.
-- `TEST_BASE_URL`: the root URL the browser will navigate to (e.g. `http://localhost:3000`).
-- `TEST_APP_ID` _(optional)_: an application or workspace identifier passed to tests that need to target a specific app instance. When unset, tests run against the default app/workspace returned by the base URL.
-
-If the file is missing, instruct user to copy `tests/.env.example` to `tests/.env`.
-
-### 2. Connect to Chrome
-
-```
-mcp__claude-in-chrome__tabs_context_mcp with createIfEmpty: true
-```
-
-If connection fails: Install Claude-in-Chrome extension, ensure Chrome is running.
-
-### 3. Setup Browser
-
-```
-mcp__claude-in-chrome__tabs_create_mcp
-```
-
-Navigate to `${TEST_BASE_URL}`. Login if required using credentials from step 1.
-
-### 4. Verify Ready State
-
-Confirm main dashboard is visible before proceeding.
-
-## Execution
-
-1. **Locate test file**: `.github/docs/tests/<test-name>.md`
-2. **Validate exists**: If not found, list available tests in `.github/docs/tests/`. If that directory does not exist, search for common test patterns: `*.test.*`, `*.spec.*`, `__tests__/`, `test/`, `tests/` directories, or check `package.json` for a `test` script to determine how tests should be run.
-3. **Create results file**: `tests/claude-runs/<test-name>-<YYYY-MM-DD-HHmmss>.md`
-4. **Execute sequentially**: Update checkboxes as you go
-5. **Save results**: Write completed file with summary header
-
-## Checkbox Markers
-
-| Marker | Meaning                             |
-| ------ | ----------------------------------- |
-| `[x]`  | Passed                              |
-| `[!]`  | Failed - add `**FAILED**: <reason>` |
-| `[-]`  | Skipped                             |
-| `[ ]`  | Not run                             |
-
-## Results Template
-
-```markdown
-# Test Results: <Test Name>
-
-## Execution Summary
-
-| Property    | Value                           |
-| ----------- | ------------------------------- |
-| Test File   | `<path>`                        |
-| Executed At | `<YYYY-MM-DD HH:mm:ss>`         |
-| Status      | `PASSED` / `FAILED` / `PARTIAL` |
-
-## Results Overview
-
-| Metric           | Count |
-| ---------------- | ----- |
-| Total Assertions | X     |
-| Passed           | X     |
-| Failed           | X     |
-| Skipped          | X     |
-
-## Failed Assertions Summary
-
-- Section X.X: <failure description>
-
----
-
-## Test: <Original Title>
-
-... (test content with updated checkboxes)
-```
-
-## Error Handling
-
-- **Network errors**: Retry once, then mark failed
-- **Timeout**: Mark failed with timeout note
-- **Element not found**: Screenshot, mark failed, continue
-- **Browser disconnect**: Stop, save partial results, inform user
-
-## Screenshots
-
-Take screenshots: before each major section, on failures, after completion.

package/data/harnesses/apollo/skills/testing/SKILL.md

@@ -1,166 +0,0 @@
----
-name: testing
-description: "The test-lifecycle skill — three modes. Plan-gate mode: after `boundary` passes, derives the tests a plan owes and writes the Test Obligations ledger into the plan (a row per behavior: layer, target file, oracle, fixtures); writes no test files. Placement mode: layered test strategy — which ownership strata the application has, where a test lives and what it may assert; use for any testing-strategy, test-architecture, test-pyramid, or 'unit/integration/e2e?' question, even if 'layer' is never said. Gate mode: executes the verification gate — derives the behavioral checklist, drives the real surface (browser automation, the real CLI, HTTP; the `/test` runner where wired), pins durable behaviors, discharges every ledger row. Triggers on 'test plan', 'testing strategy', 'test architecture', 'test layers', 'where should this test live', 'run the verification gate'."
----
-
-# Testing — Ledger, Layers, Gate
-
-One skill owns the test lifecycle's three procedural moments; the standing constraints (regimes, deferral, gate preconditions) are `.claude/rules/testing.md` and are never restated here. Pick the mode from the moment:
-
-| Moment | Mode |
-| --- | --- |
-| Plan gate, after `boundary` passes | **Plan-gate** — derive what the plan owes |
-| A strategy / placement / altitude question, or laying out a suite | **Placement** — derive the strata, place the tests |
-| The user triggers the verification gate | **Gate** — drive, pin, discharge |
-
----
-
-## Plan-gate mode — the Test Obligations ledger
-
-You derive the tests an implementation plan owes and pin them into the plan as an explicit, reviewable manifest — at the same gate `boundary` runs, ordered second. You never write a test file; you write the **ledger gate mode discharges**, so the gate proves a checklist instead of a vibe.
-
-**The litmus is "which promise, at which altitude, proven by what?"** A plan promises behavior; each promise earns exactly one test at the cheapest layer that can actually prove it. Spend your reading deciding the *layer* and the *oracle*, not on prose. Writing tests *before* the code exists fabricates implementation coupling or leaves the suite red for the plan's duration; writing them *during* the build loop taxes every iteration — so the plan gate emits obligations, the loop stays free of test files, and gate mode discharges the manifest in one pass.
-
-### Contract sources
-
-- **The plan's Proposed Changes** — each file/entity/API change is a behavior that may owe a test.
-- **The owning LLD** (`docs/features/{feature}.md`, via the ownership index) — every obligation names the LLD promise it proves; the LLD is referenced, never restated. This one-directional chain (LLD → manifest → tests + Completion checklist) is what stops the artifacts drifting.
-- **`.claude/rules/testing.md`** — frameworks and canonical placement per stack; target paths come from there, never invented. The repo's existing runner always wins.
-- **`boundary`'s output** — a HIGH/CRITICAL finding is itself a behavior owed a regression test. Fold boundary's amendments first, then read the amended plan.
-
-### Layer assignment
-
-Assign each behavior the **cheapest layer that can prove it**, then name the oracle. The ledger altitudes are `unit` / `component` / `integration` / `e2e` (strata mapping: § Bridge below); **integration is the default for server behavior** — a route/handler against a real in-memory datastore via the app instance. Error paths, races, and idempotency are obligations too, and belong at **integration** with injected faults (network mock, fake timers, forced constraint) — never e2e.
-
-**The e2e altitude gate:** an e2e obligation is earned **only** when the behavior genuinely spans processes no single-process test can exercise together. Density is one scenario per cross-process journey, not per feature — prefer **"extend scenario `<name>`"** over **"new scenario"**. **Refuse to emit any e2e obligation while the project's e2e smoke gate is not wired in CI** — emit a **blocked** row naming the missing gate instead.
-
-### Run (plan-gate)
-
-**Input:** a plan path (given, or the newest in `docs/history/plans/`), boundary-checked with amendments folded; skipped on a boundary BLOCK. For a non-plan diff, the hunks stand in for Proposed Changes but the obligations are paid **immediately** — only a plan has a ledger to defer into.
-
-1. **Build the behavior list** from Proposed Changes + the LLD's promises + HIGH/CRITICAL boundary findings. Note compiler-guarded behaviors — they owe **no** test.
-2. **Assign layer + oracle** per behavior; cheapest proving layer wins.
-3. **Map to a target file** per `testing.md`; name fixtures/factories and fault injection; use the repo-standard fake-data source.
-4. **Apply the e2e altitude gate**; downgrade everything else to integration.
-5. **Emit the Test Obligations section into the plan** (an executor dispatched with only the plan sees nothing else), plus a one-line chat summary:
-
-   ```
-   ## Test Obligations
-
-   | # | Behavior (LLD promise) | Layer | Target file | Oracle | Fixtures / faults |
-   | - | ---------------------- | ----- | ----------- | ------ | ----------------- |
-
-   Coverage: {N} behaviors · {N} integration · {N} component · {N} unit · {N} e2e ({N} extend, {N} new)
-   Completion checklist: docs/tests/{feature}.md  (derived at the gate, not now)
-   ```
-
-   A behavior with no obligation is stated too, with the reason — "none — compiler-guarded" reads as *checked*; an empty cell reads as *not analyzed*. A short manifest is valid — do not pad.
-6. **Record the write in the plan's `Gates:` line**, rewriting only your segment to exactly `Test-plan: written YYYY-MM-DD (N rows)` — the compliance hook greps this exact form. Add the line if the plan predates the format.
-
----
-
-## Placement mode — layered test strategy
-
-You decide **where a test lives and what it may assert**. **The litmus is "where can this defect originate?"** A test lives with the only layer that can produce the defect it catches. "The 409 response carries the current body" can only break in a route handler — service-contract layer. "The buffer the user typed survives the 409" can only break in component state — component layer. Same feature, two owners, two tests, zero overlap. Placement is decided by this question alone — testing a feature wherever you first *see* it is what makes suites flat, duplicative, and multiplicative in cost.
-
-### The stack
-
-The maximum form, for a full-stack application. Each layer names what only it can break, the oracle that proves it, and the technology **class** — the concrete framework comes from `testing.md`'s stack table, never from here.
-
-| # | Layer | Owns (defects only it can originate) | Oracle | Technology class |
-| --- | --- | --- | --- | --- |
-| 1 | **Persistence schema** | Invariants the storage engine enforces against any code: uniqueness, checks, cascades, append-only triggers | The engine's refusal of a forbidden write | The real engine, in-memory — never a mock of storage you own |
-| 2 | **Domain** | Business rules and state transitions, via direct calls | Resulting state in real storage | Real datastore + modeled fakes for external ports |
-| 3 | **Service contract** | The published wire: authn/authz at the door, envelope shape, status mapping, field projection, stream/event grammar. For a CLI this is argv/stdout/exit codes; for a library, its exported API | Requests against the real app instance, in-process | `supertest` / `SELF.fetch` class — never a spawned server, never naked handler functions |
-| 4 | **Contract artifact** | Nothing behavioral. Typed fixtures / interception handlers **compiled from the provider's own types**, exported for every consumer-side test | The typechecker — drift from the provider is a compile error | No runner; a module the provider owns |
-| 5 | **Client data** | The consumer's half of the wire: error taxonomy, parsing, byte fidelity, stream reassembly, retry/abort | Intercepted network serving layer-4 artifacts; no DOM | `msw`-class interception |
-| 6 | **View logic** | Pure presentation derivations: grouping, ordering, status vocabularies, formatting | Table-driven equality | Plain runner |
-| 7 | **Component / surface** | Interaction orchestration — what a user action changes on screen: buffer lifecycle, optimistic states, error surfaces | Rendered output a user can observe; network answered by layer 4 | DOM testing-library class + interception |
-| 8 | **System smoke** | Composition only — the layers are actually stacked: the build serves, auth flows end to end, one write round-trips | A real browser or real binary against the really-running app | Browser/process driver class; 3–5 journeys, zero variants |
-
-Layer 4 is the hinge. Every layer ≥5 runs on the assumption that layers 1–3 are green — and the artifact makes that assumption *enforceable*: when the provider's response type changes, the fixture stops compiling, and every consumer test fails at typecheck before it runs. A consumer-side test that hand-writes a wire response has smuggled unverified layer-3 knowledge upward; route it through the artifact.
-
-### How many layers — derived, never chosen
-
-**A layer exists iff the application has the boundary that can originate that layer's defects; an absent boundary makes the layer vanish** — it never merges into a neighbor. Merging is the failure mode: "simplifying" layers 3 and 7 together reinvents the flat feature test, where every UI assertion silently re-verifies the API beneath it and cost goes multiplicative again.
-
-| Application shape | Strata present |
-| --- | --- |
-| Full-stack web app | all eight |
-| Backend-only service | 1, 2, 3, 8 |
-| CLI | 2, 3 (the CLI's argv/stdout contract), 8 |
-| Frontend on a third-party API | 4 (derived from the API's published spec), 5, 6, 7, 8 |
-| Library | 2 only — its exported API is the contract, its tests are its consumers |
-
-Derive the stack first, then place tests: a placement argument that starts "this feels like an integration test" has skipped the derivation.
-
-### Placement discipline
-
-- **An assertion provable at two layers is misplaced — it belongs at the lower one.** The duplication check is mechanical, not judgment.
-- **Behavior variants sink to the cheapest layer that owns them** — almost always 2 or 6. A variant at layer 3 pays wire tax on a domain test; a variant at layer 8 is a placement failure below, by definition.
-- **One representative path upward.** Layer 3 keeps one happy path per route plus exhaustive coverage of *contract edges only*; layer 8 keeps 3–5 journeys total.
-- **External systems enter as modeled fakes, not spies.** A fake implements the port's semantics so tests assert resulting state; a spy only proves methods were called, which passes just as happily with the bytes swapped.
-- **Failure localization is the payoff to protect.** One defect turns exactly one layer red, at its owner. When a single change reddens several layers, at most one of those tests was correctly placed — treat the rest as findings.
-
-Layering makes cost **additive** — a new API behavior costs one layer-2 test and maybe a layer-3 edge, zero frontend tests; a new UI state costs one layer-7 test, zero backend tests. A flat suite pays N×M, because every top-layer path implicitly re-verifies every behavior beneath it.
-
-### The tree
-
-```
-tests/
-  schema/      L1 — infrastructure-bound runner (real engine)
-  domain/      L2 — infrastructure-bound runner (real storage, modeled ports)
-  routes/      L3 — infrastructure-bound runner (in-process app)
-  contract/    L4 — no runner; typed fixtures + interception handlers
-  client/      L5 — plain unit runner
-  view/        L6 — plain unit runner
-  component/   L7 — unit runner + DOM environment (per-file opt-in)
-  helpers/     shared seeds, fakes, and builders — owned by no stratum
-e2e/           L8 — its own config, never mixed into the unit runner's glob
-```
-
-- **A stratum the app lacks gets no directory** — an empty `component/` in a backend service is a lie about the app's shape.
-- **One shared glob list, imported by both runner configs** — two hand-maintained lists drift; one imported constant cannot.
-- **Concrete runner, framework, and DOM environment come from `testing.md`'s per-stack table** — this skill names the slot, never the brand.
-- **Contract modules the provider binds** (the layer-4 source types) live in the app's shared source zone — importable by both sides; `tests/contract/` holds only the compiled fixtures and fakes.
-
-### Bridge to the obligation ledger
-
-The ledger's altitudes are coarse names for where a test *runs*; the strata say what it may *assert*:
-
-| Ledger altitude | Strata it covers |
-| --- | --- |
-| unit | 2 (pure domain), 5, 6 |
-| integration | 1, 2 (stateful), 3 |
-| component | 7 |
-| e2e | 8 |
-
-When writing or discharging a ledger row, name the stratum, not just the altitude — "integration" alone leaves open whether the row asserts a schema invariant, a business rule, or an envelope: three owners, three oracles.
-
-### Run (placement)
-
-1. **Derive the stack** from the application's real boundaries (storage? published wire? separate client? DOM?).
-2. **Place each behavior** by the litmus; name stratum, oracle, technology class; take the concrete framework and file placement from `testing.md`.
-3. **Flag violations, don't just place** — assertions provable lower, variants above 2/6, hand-written wire fixtures above layer 4, spies where fakes should model state, layer-8 variants.
-4. **Report as a stratum map** — one line per stratum: exists/absent (why), what lives there, what is misplaced and where it moves. For a plan, feed the strata into the ledger's rows.
-
----
-
-## Gate mode — discharge the ledger
-
-Runs only when the user triggers the verification gate (constraints — preconditions, verdict-inline, tier, honesty — are `.claude/rules/testing.md` § The gate). **Drive the real thing first, then pin what must not regress**: driving finds the defects that matter to a user, and shows which behaviors are worth the permanent cost of a test.
-
-1. **Write the checklist** — derive or update `docs/tests/{feature}.md` from the ledger and the LLD's promises (the `documentation` skill's `templates/behavioral-checklist.md`; one `**Assert**` per observable). Derived before the driving it is the script; derived after, it is merely a report with nothing to trace tests back to.
-2. **Drive the real surface** — browser automation for web UI (the `/test` runner skill where the repo wires it), the actual CLI binary, HTTP against the running worker. **A failing checklist assertion is never softened to make a run green** — record the defect, send it to the backlog. Where the runtime offers no browser automation, emit the browser-verification checklist for the user to run; their report is the rung's verdict and `Status: Complete` waits for it.
-3. **Pin the durable behaviors** as suite tests per `testing.md`, naming each test's stratum (§ Bridge). A test is a permanent maintenance cost, bought deliberately:
-
-   | Earns a suite test | Verified by driving alone |
-   | --- | --- |
-   | A promise an LLD makes about the feature's contract | Layout, spacing, copy — restated by a test, not protected by one |
-   | A bug that occurred once — its regression test | A one-off migration or backfill's output |
-   | An error path, race, or idempotency guarantee | Behavior a type or the compiler already makes unshippable |
-
-   A driven check is evidence, not an artifact — it proves the change works today and leaves nothing behind; that is why this rung exists.
-4. **Run the affected suite**, plus the project's e2e smoke gate where one is wired.
-5. **Discharge every ledger row into exactly one outcome**: **satisfied** (test green, or driven check passed), **owes nothing** (with the reason — compiler-guarded, covered elsewhere), or **blocked** (missing infrastructure named, row converted to a backlog item). A row left unexamined blocks the gate.
-6. **Report results honestly, including failures**; record which test now guards each checklist section (`Pinned:` traces). Completion steps — freezing the plan, the changelog entry — are the root policy file's, not yours.