@hellraisercenobit/ai-engineering-gate 0.8.0

package/skills/engineering/transpose-testing-patterns/references/suite-contract.md

@@ -0,0 +1,270 @@
+# Transpose/review contract 1.1.0
+
+Canonical source: `contracts/suite-contract.md` in hellraisercenobit/skills. Copies in
+transpose bundles are generated by `npm run sync:contract`; never edit them by hand.
+The repository maintainer owns this contract. Domain catalogs and record schemas remain
+owned by their transpose skill. Read this contract once per execution.
+
+1.1.0 adds clauses to 1.0.0 and changes none of its guarantees. Each member declares the
+contract versions it supports in the member manifest. A workflow that runs on records,
+checks and independent reports without any gate stays valid under 1.1.0: the clauses below
+describe what enforcement derives, never a new obligation on prose.
+
+## Guarantees
+
+| ID | Requirement | Evidence |
+| --- | --- | --- |
+| C01 | One normative catalog per dimension, owned by transpose and read by review. | Resolved local references and identified versions or content hashes. |
+| C02 | Explicit scope and comparison base. | Files and sites, including relevant uncommitted and untracked files. |
+| C03 | Inventory every relevant site, including retained choices. | Domain criteria, alternatives and observable invariants. |
+| C04 | Record each decision before the first affected implementation write. | Schema-valid records outside the repository; preserve previous revisions and reasons. |
+| C05 | Separate deterministic checks from semantic judgment. | Schema/catalog membership and applicable type, runtime, lint and build checks. |
+| C06 | Independent reviewer with a neutral brief. | Fresh context without builder history or rationale; original request and factual constraints only. |
+| C07 | Freeze expectations before reading records or author justification. | Immutable expected matrix in the review transcript; no `git log`, PR rationale or author analysis. |
+| C08 | Compare every site; steelman every candidate finding. | Expected/recorded/actual, exact rule, evidence, strongest defense and refutation. |
+| C09 | Reviewer changes no files and delegates no review. | Report in its response; the builder fixes and dispatches a new fresh reviewer. |
+| C10 | Only a current `SOUND` completes transposition. | Complete audit, zero confirmed findings, passing applicable checks and no unresolved dispute. |
+| C11 | Only the reviewer attests; scope changes invalidate its verdict. | Examined state identified; the gate computes the fingerprints a verdict binds to. |
+| C12 | Missing prerequisites and limits are explicit. | No invented rules, support, independence or attestation. |
+
+## Shared execution rules
+
+Resolve companions, schema, catalog, this contract and any **required** guides first. Pin
+their versions or hashes for the execution. A missing optional guide is acceptable only
+when the domain permits catalog-only decisions. Conflicting installed contract/catalog
+versions are an incomplete prerequisite; do not silently download another version.
+
+The builder inventories scope, compares alternatives including the current implementation,
+records, then writes and checks. Coherent local choices can share a record if every site
+remains identifiable. `none` has the domain's explicit meaning; it is not a shortcut around
+evaluation. No applicable site is a justified non-applicable dimension, not an artificial
+`SOUND`. Do not add common fields to a domain schema that forbids them: coordination
+metadata belongs in an external execution index.
+
+The reviewer reads independent requirements and factual constraints, inventories the scope
+and freezes a matrix of expected acceptable choices, rules and invariants **in its response
+before the next tool call that opens records**. It then compares expected, recorded and
+actual. Record absence is not a retrospective code defect in a standalone audit; a claimed
+completed transposition requires its records. State significant exposure to author
+justification. A contaminated brief requires a new reviewer before completion; do not
+rewrite the frozen matrix to match the builder. Verified new facts that change premises
+require a new framing and fresh review, retaining the old matrix.
+
+For each candidate, construct the strongest defense (compatibility, public contract, domain
+meaning, framework semantics, proven cost or legitimate simplicity). Drop it if that defense
+holds. Confirm only with an applicable catalog rule and evidence. Report catalog gaps
+separately, without severity or verdict impact. A gap is not permission to invent a rule.
+
+Reports identify scope/base/state, reference versions, coverage, frozen matrix, comparison,
+confirmed findings, defended choices, gaps and check evidence. Each finding identifies
+location, rule, expected/recorded/actual, impact, defense, refutation and proposed correction.
+Severity: `Blocker` for concrete correctness/support failures, `Major` for demonstrated
+structural costs or missing guarantees, `Minor` for evidenced idiomatic drift after defense.
+Age or taste alone is never evidence. This clause owns the severity tiers; a domain skill
+references it instead of restating them.
+
+| Verdict | Meaning |
+| --- | --- |
+| SOUND | Complete audit, zero confirmed findings. |
+| SMELLS | Confirmed findings, no Blocker. |
+| VIOLATIONS | At least one Blocker. |
+
+An incomplete execution reports the missing prerequisite and has no attestable quality
+verdict; it is not a fourth verdict. The reviewer edits neither code, records, catalogs nor
+fixtures. Its report is a response that the harness can save externally. Its sole permitted
+external mutations are the gate's attestation and report operations, when supported;
+attestation accepts `SOUND` only. A dispute goes to the user and remains unresolved until
+decided; it is not a fix.
+
+## Dimension registry
+
+The member manifest `contracts/members.json` is the registry. It owns, per member: the
+dimension identifier, the transpose and review skill locations, the reviewer agent, the
+decision schema, the evidence schemas the dimension owns, the reference bundle, the contract
+versions the member supports, and a status, `implemented` or `qualified`. Nothing else
+defines a dimension identifier, and no other file lists the dimensions.
+
+The registry holds orchestration metadata and schema locations only: never a rule, a pattern
+name, an idiom or a test form. Adding a dimension is a registration plus a qualification. It
+never changes enforcement logic and never adds a hook.
+
+## State and evidence
+
+Store evidence, derive state. Every durable fact is a schema-valid document on disk: a
+declaration, a decision record, an evidence append, an attestation, a report, a dispute or
+an arbitration. No implementation persists a workflow boolean such as "reviewed" or
+"fresh"; state is recomputed from those documents and from the code they cover.
+
+A project opts in with one committed marker at its repository root, which also carries the
+project's dimension selection and its evidence and export locations. Without that marker,
+enforcement is silent and every workflow stays portable. Evidence lives outside the
+checkout, under a task key derived from the branch.
+
+### Declaration
+
+Before the first record, a task declares each registered dimension applicable or
+non-applicable, with a reason, the requester's wording of the request and the factual
+constraints. An applicable declaration also names its scope, as repository-relative file
+paths or directory prefixes, and the relevant configuration files. A non-applicable
+dimension has a declaration and nothing else: skipping a dimension is a recorded decision,
+never a default, and an undeclared registered dimension is an incomplete task.
+
+The declaration is what protects the scope and what a neutral brief is rendered from. It is
+revisioned like a record, and it locks once a record, report, review window or dispute
+depends on it, unless the revision only widens scope or adds constraints.
+
+### Fingerprints
+
+"Current" means three fingerprints.
+
+- **Source**: the content hashes of the union of the declared scope paths, the declared
+  configuration files and the change set. The change set is the tracked diff between the
+  merge-base of the recorded base and HEAD, plus staged, unstaged and untracked files, minus
+  the export directory, the gate-owned paths and the marker's ignore patterns. Content
+  hashes only: the base revision is recorded and not hashed, so a content-neutral rebase
+  does not expire a verdict, and a clean HEAD never identifies a dirty worktree. Change-set
+  paths outside every applicable declaration are reported as undeclared changes.
+- **Reference**: the content hashes of the dimension's reference bundle as distributed —
+  catalog, decision schema, evidence schemas, guides, the review skill's references and the
+  generated copy of this contract — plus the contract version and the gate version.
+- **Decision**: the ordered hash of the dimension's declaration and of every decision record
+  of the dimension for the task, each with its revision number.
+
+A verdict is current only while all three fingerprints it was bound to still match. Any
+mismatch is stale. Eager marking by a PostToolUse hook is an optimization and is never
+authoritative: a skipped hook, a crash or an editor outside the harness must never leave a
+stale verdict looking current, so expiry is always derived from the fingerprints.
+
+### Envelopes
+
+Every decision record carries a common outer envelope: dimension, schema version, catalog
+version, the contract versions it supports, need, scope as an array of paths, base, revision
+as number, previous and reason, and two typed lists — `cites`, artifacts and evidence
+sources that exist when the record is validated, and `plans`, artifacts the record commits
+to produce, each with its dimension-defined role. The dimension-specific body stays owned by
+the dimension schema. Applicability is not a record field; it lives in the declaration.
+
+`cites` carries referential integrity. A cited path that does not exist refuses the record.
+A claim of unknown about a checkable fact — targets, runtimes, environments, configuration —
+is accepted only with the sources consulted cited, or with the paths searched and not found.
+A revision that announces a correction is refused when no cited artifact changed: a record
+describes what was done, not what should have been. `plans` are not checked when the record
+is written, so a record that precedes the first affected write stays valid under C04; every
+planned artifact must exist before a review begins, is filed or is dispatched.
+
+Every review emits a common review envelope: dimension, the supported contract version, the
+verdict, the records examined, the checks it saw executed, a reviewer object with an
+independence claim and a declared identity, the confirmed findings and the
+challenged-survived list. Each finding has an identifier and a kind, `evidence` or
+`judgment`; an evidence finding carries a typed remedy, a judgment finding the proposed
+correction C08 already requires. The envelope carries no fingerprint: a fingerprint a
+builder or a reviewer writes anywhere is ignored.
+
+### Attestation and report
+
+The gate writes both, and they are the reviewer's only permitted external mutations. An
+attestation stores a `SOUND` envelope together with the three fingerprints of the reviewer's
+window and its captured identity. A report stores a `SMELLS` or `VIOLATIONS` envelope bound
+the same way; it blocks completion until a `SOUND` attestation on a later state, or an
+arbitration closing its last open finding, supersedes it. No other verdict is attestable and
+no verdict is a score.
+
+### Findings, disputes and arbitration
+
+A finding admits two responses: address it — the remedy executed and the artifact appended,
+or the record revised and the state moved — or dispute it with a pointer to existing
+counter-evidence. An answer in prose is neither, and a changed fingerprint alone addresses
+nothing. Findings about evidence say evidence not on file, never false claim: the builder is
+asked to file, not to confess.
+
+While any finding of the last report is pending, no new review of that dimension begins, so
+the same finding is never re-litigated with a fresh reviewer. A valid dispute blocks
+completion and goes to the user; it never goes to another reviewer on the same state. Its
+only exit is an arbitration that only a human hand writes: `uphold` closes the finding,
+`reject` puts its remedy or correction back to pending.
+
+### Reviewer identity
+
+Every gate call carries the harness session identifier. A reviewer's calls carry an agent
+identifier that must differ from the builder's. This checks consistency, not independence.
+Where a harness provides no agent identifier, the attestation is stored unverified, the state
+says so, and a pipeline may require verified identity.
+
+### Completion
+
+For each registered dimension: a non-applicable declaration needs its reason; an applicable
+one needs at least one validated record, every planned artifact produced, a current `SOUND`
+attestation, no current report with an open finding and no unresolved dispute. An undeclared
+registered dimension is incomplete. Any incomplete dimension blocks completion whatever the
+others say. Requirements combine; they never average, and there is no score.
+
+Deterministic checks stay the reviewer's responsibility under C10 and appear in the review
+envelope as the checks it saw executed. Enforcement validates their presence, never their
+result.
+
+## Neutral brief
+
+Send only the filled fields below to the named reviewer or a fresh general subagent with
+no inherited conversation. Keep test expectations and other reviewers' conclusions out.
+
+```text
+You are the fresh <dimension> reviewer. Run /<review-skill> yourself; do not delegate.
+Read-only: do not modify any file, including code, records, catalogs or fixtures.
+Scope: <exact paths/symbols>; repository: <absolute path>.
+Base: <ref/commit or standalone>; include relevant uncommitted and new files.
+Use git diff and file reads, never git log or PR descriptions.
+Original request: <requester wording, without builder choices or rationale>.
+Factual constraints: <project targets, public contracts, independent sources>.
+Records: <paths; check existence only until the expected matrix is frozen>.
+Check evidence: <paths; read results after freezing, not implementation rationale>.
+Undeclared changes: <change-set paths outside every declaration>.
+Report your frozen matrix before opening the records. End with the domain report
+and one verdict, or explain incomplete execution without attestation.
+```
+
+## Composition and expiry
+
+One builder coordinates all applicable dimensions. Keep their records and verdicts distinct.
+Historical transforming reviews run before final reviews. Independent reviewers can run in
+parallel on one frozen final state, without exchanging rationale. Completion requires all
+applicable dimensions `SOUND` on that same state; one verdict cannot compensate for another.
+
+Any change to a file in a review's scope invalidates it, including prose. Shared files
+invalidate all covering reviews. Without precise scope tracking, invalidate the whole
+change's reviews. Identify the state with a commit plus the staged/unstaged diff and
+untracked file contents or hashes; a clean HEAD alone does not identify a dirty worktree.
+Record/schema/catalog changes also reopen the affected review. No generic orchestrator
+is implied. An external index of scopes, hashes, record paths, checks and responses is enough.
+
+A correction for one dimension moves the change set and therefore expires every verdict of
+the task, because every reviewer's brief covers the whole diff. Corrections are therefore
+batched: address every pending finding of every dimension, then reopen all applicable
+reviews together on one state, frozen while they are in flight so no verdict binds to code
+its reviewer never read. A review filed on a state that moved since it began is void.
+
+If domain requests conflict, identify the incompatible invariants and reopen decisions
+before writing. A dimension that turns non-`SOUND` on a state produced by correcting another
+is a cross-dimension conflict, which the next briefs carry. Stop a repeating conflict for
+user arbitration; never force a verdict. Bound the conflict rounds and the total rounds, and
+send a task that reaches either bound to the user rather than looping.
+
+## Gate and portable execution
+
+Inspect the installed gate's help/capabilities before using a dimension. Never invent CLI
+flags, reuse a different dimension or treat a refused record as an absent gate. A gate
+validates shape, membership and referential integrity; the reviewer owns semantic judgment
+and only attests SOUND. The gate computes its own fingerprints and accepts none. Fix a
+refused record before continuing that workflow.
+
+The suite's own gate is `ai-engineering-gate`, generic by construction: it derives state from
+evidence and holds no domain rule. Enforcement it applies covers omission, drift and stale
+evidence, not a deliberately forged evidence index. A harness Stop hook is advisory by design
+of the harnesses; the lock on publication is the gate's exit code, consumed by a delivery
+pipeline gate or a CI check.
+
+Without a compatible gate, portable completion consists of validated records, successful
+checks and an independent report tied to the examined state. It provides no automatic
+enforcement or lock. If the project's workflow requires gate attestation, an absent or
+unsupported gate leaves that workflow incomplete; portable evidence cannot replace it.
+Keep evidence available through review/correction; do not reconstruct missing historical
+decisions as if they preceded implementation.

package/skills/engineering/transpose-testing-patterns/references/tdd.md

@@ -0,0 +1,62 @@
+# TDD and process evidence
+
+Applies TP-06/07/15/16. Choose `tdd`, `characterization`, `coverage` or `audit` in the
+record. Existing tests that pass immediately are useful coverage, not an observed TDD cycle.
+
+1. Name the behavior, independent requirement, public seam and discriminating example.
+   Record before tests, determinant helpers, configuration or production changes.
+2. Write one behavioral slice. Run it. An import/setup error is setup work, not RED.
+   A minimal public skeleton can make the intended assertion reachable. For a static
+   guarantee, isolate the expected diagnostic for the missing type contract.
+3. Preserve test/oracle and determinant helper contents. Implement the behavior to GREEN.
+   Changing the test to obtain GREEN starts a new cycle and preserves the old observation.
+   Do not add speculative features; an obvious naturally general solution is allowed.
+4. Run the focused scenario and relevant regression checks. Map scenario IDs to executed
+   test identities. Record discovered counts, skips/todos/fails and retries explicitly.
+5. Before refactoring, name concrete pressure: duplication, extension cost, fragile
+   invariant or confused responsibility. Keeping the design is valid. Preserve observable
+   contracts; green alone is not full equivalence. Compare with the legacy/reference or
+   add a discriminating probe when the risk warrants it. New behavior needs its own cycle.
+
+Keep an append-only external JSONL journal linked to the initial record, one event per phase,
+validated against `journal-event.schema.json`:
+
+```json
+{"record":"rec-001","scenario":"boundary","phase":"red","command":"npm test -- --run boundary.test.ts","exitCode":1,"cause":"expected 10, received 0","failureClass":"expected-behavior-missing","output":"runs/red.txt","state":"snapshots/red/"}
+```
+
+This is a format example, not evidence. Capture output from the actual tool and preserve
+accessible snapshots or resolvable immutable refs for RED, GREEN and any relevant refactor.
+Every event names its **failure class** when its phase is red, so an absent behavior is
+distinguishable from a behavior that exists and disagrees, and both from setup work.
+
+Artifact hashes are not written in the event. Where a gate is installed, `evidence append`
+stamps each event with the content hashes of the record's planned artifacts by role, `test`
+and `production`, so the event proves the state of those files at the moment it was filed.
+Hashes identify states but do not allow inspection of missing content. Do not overwrite
+earlier events or backfill results into the initial decision. No RED commits or empty
+reflection commits are required. Keep evidence through review and correction.
+
+## Derived states
+
+The journal is the fact; these four states are read from it, not claimed:
+
+| State | Read from the journal | What it proves |
+| --- | --- | --- |
+| `observed` | a red event, not marked replayed, whose stamped `production` hashes equal the base state, followed by a green event on the same scenario | the test failed before the production change existed |
+| `replayed` | a red and a green event the gate wrote itself while executing a replay | the test discriminates the behavior; nothing about chronology |
+| `incomplete` | a cycle missing its red or its green | the profile claims TDD and its evidence does not support it |
+| `non-TDD` | the record's mode is `characterization`, `coverage` or `audit` | another profile, judged on its own terms |
+
+A record whose mode is `tdd` and whose scenarios are `incomplete` is a false TDD claim, and a
+reviewer states it as a finding on evidence, not as an opinion. A `replayed` state answers a
+missing-RED remedy: it is proof that the test discriminates, not proof that it was written
+first, and a review says which of the two it has. The reviewer judges discrimination and
+design; chronology is the gate's stamp to read, not a claim to weigh.
+
+Portable evidence is inspectable, not tamperproof. Timestamps and commit messages do not
+prove chronology alone. Missing observations cannot be reconstructed from final source.
+A retrospective audit can assess test quality with that limit; a claimed full TDD
+transposition without its required evidence remains incomplete. The reviewer never
+modifies code or fixtures to create evidence; the builder runs requested experiments in
+an isolated copy, then a fresh reviewer examines the results.

package/skills/engineering/transpose-testing-patterns/references/transpose-codeception.md

@@ -0,0 +1,84 @@
+# Codeception adapter 1.0.0
+
+Read alongside the applicable catalog rules. Identity is **Codeception**: any installed
+`codeception/codeception` the lockfile reports. This is not "Codeception 5.0 only" and not
+generic PHPUnit. Detect the profile from the lockfile, `codeception.yml` / suite files,
+installed PHPUnit, and the command the project actually runs. Record Codeception major/minor,
+suite types (Unit/Cest/Functional/Acceptance), DB/transaction helpers, group filters and
+command. Do not key routing on an exact `5.0.0` string.
+
+A first **reference profile** pins Codeception 5.x Unit tests that talk to MySQL through
+`public UnitTester $tester` transactions. That profile is a qualification target, not an
+adoption pin and not a requirement that every Codeception project look like Unit+MySQL.
+A project without MySQL, without `@group`, or with a different `codecept` invocation still
+uses this adapter; the freeze records what is actually there.
+
+Sources checked 2026-09-18; verify support again for a different installed profile.
+Unknown or undocumented Codeception/PHPUnit majors are incomplete execution, or use the
+conservative mappings below with named unknowns. Never treat PHP as close enough to Vitest.
+
+## Detect and route
+
+If `codeception/codeception` is present, load this adapter. Patch, minor and major differences
+stay in the capability table. Do not fall back to catalog-only because the version is not 5.0,
+and do not silently migrate to Vitest.
+
+| Detected fact | Record when present | Do not invent |
+| --- | --- | --- |
+| Lockfile `codeception/codeception` | major/minor (4.x, 5.0.x, 5.1.x and other installed ids) | an exact 5.0.0 pin |
+| Suite type | Unit, Cest, Functional, Acceptance from config/paths | Unit+MySQL for a pure Acceptance suite |
+| `UnitTester` + `startTransaction` / `endTransaction` | DB isolation on `$this->tester` | a jsdom or "pure unit" claim |
+| `@group` / CI filter | TP-16 execution filter | a group rule the project does not use |
+| Actual invocation | compose, `vendor/bin/codecept`, CI image | a guessed `codecept` path |
+| `Codeception\\Stub` and PHPUnit doubles | APIs on the installed pair | `vi.fn<(...)>()` |
+| `loadMfb` / `getLegacyController` | existing entry to legacy controllers | a new port |
+| `getDefaultAccountId` / `tests/resources/modelHelper` | project helpers that exist | those helpers on a project that lacks them |
+
+## Capability table
+
+Map each TP family from **profile predicates**, not from a single frozen 5.0 column.
+
+| Catalog families | Profile predicate | Transposition |
+| --- | --- | --- |
+| TP-01/02/06/15 | Cest or Unit methods exist | Direct methods, explicit assertions. Snapshots unavailable unless the profile already has a snapshot tool |
+| TP-03/04/08/10 | `Codeception\\Stub` / PHPUnit doubles on the installed pair | Those doubles at the chosen seam. No Vitest generics. Module-mock hoisting unavailable |
+| TP-05 | A PHP property library is already in the lockfile | Use that library. Otherwise unavailable; do not add `fast-check` |
+| TP-07/16 | Detected invocation and, when configured, `@group` / CI filters | Recorded command = actual command. Absence of a group filter is not a finding |
+| TP-09 | A project helper is present in the suite | Use that helper. If none exists, do not invent `getDefaultAccountId` or `modelHelper` |
+| TP-11 | An existing entry is present | Use that entry. If `loadMfb` / `getLegacyController` are absent, do not invent a port |
+| TP-12 | PHP | Unavailable. No `expectTypeOf` |
+| TP-13 | PHPUnit/Codeception teardown | Teardown hooks and, when present, DB transaction lifecycle. No JS fake timers |
+| TP-14 | Suite actor / DB | Environment from the suite. MySQL when the Unit tester uses it; otherwise the suite's actor. `Codeception\\Test\\Unit` does not automatically mean no I/O |
+
+## Isolation and environment
+
+When the profile uses `$this->tester` plus transactions against a database, isolation is
+that transaction lifecycle, not a mocked database under a Unit class name. Recale "pure
+unit", jsdom and Vitest Browser Mode claims. A Unit path that talks to MySQL is still this
+adapter; name the remaining integration risk.
+
+Account identity and model helpers belong only when those symbols exist. Legacy `app/`
+controllers belong only through the existing `loadMfb()` / `getLegacyController()` entry.
+
+## Doubles and errors
+
+Use `Codeception\\Stub` and the PHPUnit doubles that ship with `Codeception\\Test\\Unit` on
+the installed pair. Keep the seam honest: a stub is not a fake, and a fake's policy needs
+its own owner. Do not emit `vi.fn`, `vi.spyOn`, `vi.mocked`, `test.extend` or hoisted
+`vi.mock`.
+
+Error recipes must reject a wrong class with the same message, a missing exception and an
+accidental error. Message matching alone does not establish class. Inspect one observed
+failure instead of invoking a stateful action twice.
+
+## Commands and builder limits
+
+RED/GREEN must use the project's actual invocation, for example
+`docker compose run --rm --no-deps -T cli vendor/bin/codecept run --no-colors <path>` when
+that is what CI or the worktree runs. Do not invent a local `vendor/bin/codecept` if the
+project never uses it. Map required scenarios to executed test identities. Honor `@group`
+filters when CI actually applies them.
+
+Never copy Vitest `test.extend`, `vi.fn`, `expectTypeOf`, snapshots or `fast-check` into
+PHP tests. Catalog families stay runner-neutral; this adapter chooses APIs from the detected
+profile only.

package/skills/engineering/transpose-testing-patterns/references/transpose-karma-jasmine-angular.md

@@ -0,0 +1,73 @@
+# Karma + jasmine-core + Angular TestBed adapter 1.0.0
+
+Read alongside the applicable catalog rules. Identity is **Karma + jasmine-core +
+Angular TestBed**, not generic Jasmine and not a pinned Angular patch. Detect the
+family from lockfile, karma config and Angular project signals, then map capabilities
+from the **installed** profile. Neighbouring majors that still use TestBed plus Karma
+stay on this adapter.
+
+Reference profile 1 (a test target, not a supported-version list): Angular 10.2.5,
+Karma 6.3.4, jasmine-core 3.5, TypeScript 4.0.5, with
+`strict` / `noImplicitAny` / `strictNullChecks` / `noImplicitThis` off, ChromeHeadless
+when that launcher is configured, and optional drifted-spec quarantine when the project
+already has one. Record the derived compiler target, majors, browser and unavailable
+families before opening records. An unknown major that still looks like this family is
+incomplete execution or a conservative mapping with named unknowns, never a Vitest
+fallback.
+
+## Detect and route
+
+Require Karma, jasmine-core, `@angular/core`, a karma config and an Angular project.
+Plain jasmine-core without TestBed/Karma does not route here. Vitest lockfiles route to
+the Vitest adapter. Missing required signals are unknown or `complete: false`, never
+Vitest.
+
+Inspect lockfile versions, `karma.conf`, `test.ts` / `include` discovery, tsconfig
+target and strictness, browserslist / `customLaunchers`, and npm scripts. Compiler and
+runtime layers come from the project's tsconfig and installed TypeScript, not a
+hardcoded 4.0.5 / ES2015 line.
+
+## Capability table
+
+Predicates follow the detected profile. Do not copy a recipe that the installed
+stack cannot honor.
+
+| Catalog families | Profile predicates |
+| --- | --- |
+| TP-01/02/15 | `describe` / `it` or the installed Jasmine/Angular equivalents. No Vitest `test.for`. |
+| TP-06 | Snapshots unavailable unless the profile already has a snapshot tool. |
+| TP-03/04/08 | `jasmine.createSpy` / `spyOn` / `spyOnProperty`. Untyped `jasmine.createSpy` when types or strictness cannot honor generics; typed spies only when the compiler profile supports them. `vi.fn` is forbidden. |
+| TP-05 | Property testing unavailable unless already in the lockfile. |
+| TP-07/16 | The project's actual Karma/Angular command (`ng test`, `npm run test-headless`, or equivalent). Pass `NODE_OPTIONS=--openssl-legacy-provider` only when that app's Node/webpack already needs it. Discovery: `require.context` when `test.ts` uses it, otherwise the project's Karma files pattern. When a quarantine or skip list is present (`DRIFTED_SPECS`, `*.spec.ts.drifted`, or the project's equivalent), a green total that excludes those specs is not coverage. |
+| TP-09 | Existing TestBed modules and spec factories. No Vitest `test.extend`. |
+| TP-11 | TestBed resource ownership when tests use TestBed. |
+| TP-12 | Unavailable while `strict`, `noImplicitAny`, `strictNullChecks` and `noImplicitThis` are off; do not turn them on to make a type test pass. `satisfies` / `expectTypeOf` only when the compiler profile allows them. |
+| TP-13 | Angular async clock APIs present in the installed `@angular/core/testing` (`fakeAsync` / `tick` / `flush` / `waitForAsync` on the reference profile). Do not mix with `jasmine.clock()`. Mixing two clocks is a finding. If a later profile replaces that clock, map the installed clock, still without mixing. |
+| TP-14 | Detected browser launcher (often ChromeHeadless). jsdom, happy-dom and Vitest Browser Mode are the wrong guarantee when Karma launches a real Chrome. |
+
+## Doubles, types and TestBed
+
+Keep doubles on the installed jasmine-core API. Do not invent Vitest spies to satisfy
+TP-03. When the installed tsconfig has `strict` / `noImplicitAny` / `strictNullChecks` /
+`noImplicitThis` off, untyped spies are the honest mapping; enabling those flags to unlock
+TP-12 is out of scope.
+
+Arrange through existing TestBed modules or spec factories. TestBed owns component,
+module and HTTP testing resources that the spec creates; reset or close them according
+to the installed TestBed API, including failure paths.
+
+## Async clock and execution
+
+Use one clock. On the reference profile that is Angular `fakeAsync` / `tick` / `flush` /
+`waitForAsync`. `jasmine.clock()` in the same spec is a mixing finding. Await
+`waitForAsync` work; a swallowed rejection is a false green.
+
+Run the detected non-interactive command. If CI cannot launch ChromeHeadless, stay on
+this adapter as `implemented` and record the skip; do not substitute Vitest. Map
+required scenario IDs to executed identities and disclose skipped, quarantined and
+retried specs. A suite that hides drifted specs behind a green total has not proven
+TP-16.
+
+Sources: [Karma](https://karma-runner.github.io/),
+[jasmine](https://jasmine.github.io/),
+[Angular testing](https://angular.dev/guide/testing).

package/skills/engineering/transpose-testing-patterns/references/transpose-vitest.md

@@ -0,0 +1,111 @@
+# Vitest adapter 1.0.0
+
+Read alongside the applicable catalog rules. This is the only qualified runner adapter.
+Detect versions from the lockfile and actual commands, not package ranges alone. Reference
+profiles are Vitest 5.0.1/TypeScript 7.0.2 and Vitest 4/TypeScript 6; exact fixture versions
+and reproducible commands live in the repository's [qualification guide](https://github.com/hellraisercenobit/skills/blob/main/tests/testing-patterns/README.md).
+They are test targets, not an adoption claim or migration requirement. Sources checked
+2026-09-16; verify support again for a different installed profile.
+
+## Detect and route
+
+Record runner, compiler/checker, Node/browser, Vite, module mode, strict options, transform,
+type declarations and relevant configuration. Vitest 5 requires Node >=22.12 and Vite >=6.4.
+Its clearMocks default clears histories, not implementations; inline projects inherit
+root configuration; hoisted calls must be top level. Inspect migration differences before
+copying configuration. Keep a compatible older project when upgrading adds no needed guarantee.
+
+| Catalog families | Vitest transposition |
+| --- | --- |
+| TP-01/02/06/15 | Direct `test`/`it`, explicit assertions, reviewed snapshots only where useful |
+| TP-03/04/08/10 | Typed `vi.fn`, `vi.spyOn`, port fake, shared real/fake contract |
+| TP-05 | fast-check inside Vitest, replay seed/path and independent model |
+| TP-07/16 | `vitest run`, actual reporter output, separate compiler command |
+| TP-09/11 | Local factory first; context fixture/hooks for resource ownership |
+| TP-12 | Compiler project/consumer tests or supported Vitest type-test mode |
+| TP-13 | Awaited assertions, controlled clock/timers/barriers and cleanup |
+| TP-14 | Node, DOM simulation or real Browser Mode according to the guarantee |
+
+## Scenarios and resources
+
+Use behavior names and the project's `test`/`it` convention. `test.each` or `test.for` can
+clarify a typed table; no count threshold forces parameterization. For concurrent tests,
+use context-bound `expect` where assertion/snapshot tracking requires the test context.
+
+Plain factories suit simple fresh values. `test.extend` suits reusable resources with
+explicit scope. Current fixture builders support named extension and `onCleanup`; older
+profiles may require the documented `use` form. Register cleanup according to the installed
+API, including partial setup and failure. Do not register multiple `onCleanup` callbacks
+where only one is supported; split resources or combine teardown. Hooks and `try/finally`
+are legitimate. `using`/`await using` require both transformation and runtime disposal support.
+
+## Doubles and errors
+
+Keep signatures typed, for example `vi.fn<(message: Message) => Promise<void>>()`.
+`vi.mocked` supplies typing, not a runtime mock. Clear removes call history, reset changes
+implementation state, restore restores originals for spies; confirm exact installed
+behavior. Module mocking is justified only at the chosen seam. Use typed imports where
+supported and respect hoisting. Native browser ESM namespaces are sealed; spying on an
+export may require an appropriate supported module-spy strategy instead.
+
+Error recipes must reject a wrong class/discriminant with the same message, missing
+rejection and an accidental error. Message matching alone does not establish class.
+For a stateful action inspect one observed error instead of invoking the action twice:
+
+```ts
+const outcome = await operation().then(
+  value => ({ kind: 'resolved' as const, value }),
+  (error: unknown) => ({ kind: 'rejected' as const, error }),
+);
+expect(outcome.kind).toBe('rejected');
+if (outcome.kind !== 'rejected') throw new Error('Expected rejection');
+expect(outcome.error).toBeInstanceOf(DomainError);
+expect(outcome.error).toMatchObject({ code: 'LIMIT', message: 'Limit reached' });
+```
+
+Assert only fields that belong to the contract. The explicit guard also narrows TypeScript;
+an ordinary matcher does not guarantee narrowing. `toThrowError` is deprecated in current
+documentation. Execute recipes on each claimed profile instead of assuming matcher semantics.
+
+## Async, time, properties and environments
+
+Await/return promises and async matchers; a catch without guaranteed assertions permits
+false green. Time as input or a controlled clock handles business time. Fake timers handle
+schedulers, debounce and retry; advance tasks deliberately and restore timers even on
+failure. To prove exclusion, force overlapping operations using controlled promises and
+observe the contested effect. Timer advancement or a final total alone is insufficient.
+
+Use fast-check when input space or histories justify it. Preserve shrinking result, seed
+and replay path. Avoid a production algorithm copied into a reference model. Retain a
+simple example where it is clearer.
+
+Use Browser Mode for native browser contracts, with a real provider and engine recorded.
+The Playwright provider is still Vitest, not Playwright Test. Await browser locators and
+retrying assertions. Simulation remains valid for guarantees it faithfully models.
+For HTTP, choose port fake, MSW, local server or real isolated service by the seam under
+test. Fail visibly on unexpected requests and reset/close handlers. MSW is not a remote
+provider contract proof.
+
+## Commands and execution limits
+
+Run the installed `vitest run` non-interactively and a checker command that actually
+includes production and test files. Vitest runtime is not a typecheck; `expectTypeOf`
+alone at runtime is no proof. TypeScript 7 tooling using the older programmatic API may
+need a compatible TS6 checker. Inspect compiler included-file output when uncertain.
+
+Map required scenario IDs to executed test identities and outcomes, not just exit code.
+Expose `.skip`, `.todo`, `.fails`, filtering and retries. Honor the project's lint/build/
+coverage gates; include relevant unimported files with coverage configuration. No invented
+coverage threshold or mandatory mutation framework. Resource cases include failure cleanup.
+
+Sources: [migration](https://vitest.dev/guide/migration/),
+[test context](https://vitest.dev/guide/test-context),
+[mocking](https://vitest.dev/guide/mocking),
+[modules](https://vitest.dev/guide/mocking/modules),
+[expect](https://vitest.dev/api/expect),
+[types](https://vitest.dev/guide/testing-types),
+[timers](https://vitest.dev/guide/mocking/timers),
+[disposal](https://vitest.dev/guide/recipes/explicit-resources),
+[browser](https://vitest.dev/guide/browser/),
+[requests](https://vitest.dev/guide/mocking/requests),
+[coverage](https://vitest.dev/guide/coverage).

package/skills/engineering/transpose-testing-patterns/references/typescript.md

@@ -0,0 +1,42 @@
+# TypeScript guarantees
+
+Applies TP-12/15/16. Identify the actual compiler/checker, declarations, module mode,
+strict options, transform and runtimes. Keep these three checks distinct:
+
+| Check | Proves | Does not prove |
+| --- | --- | --- |
+| Runtime tests | Exercised observable behavior | Compilation or preserved inference |
+| Compile production and tests | Compatibility with configured types/options | All consumer guarantees or runtime support |
+| Consumer type tests | Significant valid/forbidden uses and inference | Validation of network input or runtime immutability |
+
+Protect meaningful literals/inference, const generics, discriminated unions, exhaustivity,
+narrowing, overloads, brands and optionality. Use positive counterparts for negative cases.
+Keep invalid static calls in checker-only files. For `@ts-expect-error`, give a concise why
+and verify the intended diagnostic without the directive in an isolated probe; a typo or
+missing import can otherwise satisfy the directive. Do not run invalid static-only calls
+as runtime tests. An unused directive must fail the checker.
+
+Prefer typed factories and structural doubles. Do not reach for `satisfies` unless the
+installed compiler already supports it and a typed factory is not enough. Avoid
+`any`, `as unknown as` or suppressions used to conceal an invalid contract.
+Construct malformed inputs at `unknown`, where validation belongs. A brand does not validate an
+external string and `readonly` does not freeze or defensively copy an object.
+
+Ordinary runtime matchers do not necessarily narrow types. Use a genuinely typed assertion
+such as a supported `expect.assert` or a small `asserts` function when later code needs
+narrowing and the compiler profile supports it; do not hide the issue with `!`.
+
+Where observable, test Map/Set key identity, duplicate policy and promised iteration order;
+test partial generator consumption and closure without prescribing their private data
+structure. The modern-typescript dimension owns the implementation idiom choice.
+
+Vitest runtime transforms do not typecheck by default; `expectTypeOf` is not a runtime
+type proof. Check the installed runner's type-test command or run a dedicated compiler
+project including production, runtime tests and separate consumer cases. Inspect included
+files. TypeScript 7's native compiler and tools depending on the TypeScript 6 programmatic
+API can require different compatible configurations. Never force an upgrade from a
+qualification fixture's version.
+
+Sources: [Vitest type testing](https://vitest.dev/guide/testing-types),
+[narrowing](https://vitest.dev/guide/recipes/type-narrowing),
+[TypeScript 7](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/).