@deslop/coding-standards 0.1.1082 → 0.1.1085

package/skills/review/SKILL.md

@@ -1,58 +1,60 @@
 ---
 name: review
-description: 'Read-only, evidence-backed review of code, architecture, cleanup, designs, instructions and published artifacts. Use for reviews, audits and critiques; the author owns implementation, services and browser interaction.'
+description: 'Use for any review, audit, critique or review round of code, a PR, a design, agent instructions or a PR body.'
 ---
 
 # Review
 
-Challenge the work independently. Trace the contract, try its strongest reachable counterexample and establish the consequence before reporting a defect. The author's rationale is a hypothesis, not authority. Apply the available engineering, architecture, design and testing skills by name; when one is unavailable, use the repository's explicit contracts without inventing its rules.
+Do what a short seller does to a position: build the strongest case that the work is wrong from raw evidence (the code, real runs, data), never from the author's summary or rationale. Before you report, name what a top expert in the area would check that the brief did not ask for, and check it. Load every skill the work needed (engineering for code, design for visible output, and the other skills the checkout has for the task) with the repository's `CODING_STANDARDS.md` and agent instructions; last, answer each loaded skill's Critique against the change, as its author should have: a question the change fails is a finding.
 
-## Code review
+## Findings
 
-Review the diff that the author normalized per engineering. Spend no reasoning on formatting or diagnostics that lint reports outside legacy lists; if normalization is missing, name that gap and never mutate a read-only target.
+Each finding: severity, `path:line`, the reaching input, actual and required outcome, the probe that showed it, the smallest fix.
 
-- **Depth.** Read every hand-written changed line. For generated output, review the generator change and a sample, such as one package per source format. Trace each contract through its real consumers, failure paths, concurrency and resource ownership against the merge base. Try the inputs, orderings and failures that the tests miss. When the change refactors a whole file, list each behavior the file had at the merge base and prove that each one still holds, apart from the planned change.
-- **Findings.** Report broken behavior or contracts that a real caller's input reaches. Report violations of engineering, design or `CODING_STANDARDS.md` in changed lines, and in every line of a file that the task adds or rewrites. A recurring shape that departs from its canonical example without a request is a finding. For a pattern change, run the Patterns search for the old form and report each remaining consumer. Skip what lint enforces outside legacy lists, and restyling that the change does not need.
-- **Beyond the diff.** A contradiction with an unchanged file, a stale reference that the change leaves, and a false assumption that the change rests on are findings.
-- **Not findings.** Taste without a rule, wording, hypothetical inputs, and defects that the branch neither made nor relies on.
-- **Later rounds.** Read the published pull request diff, such as `gh pr diff <number>`, and judge the whole layer as one change in every round: structure, duplication and cleanup across its files. Spend the Depth on the commits since the covered commit and their consumers, and reuse prior reads of unchanged sources. A stack overview reads every layer together and reports what crosses layers: duplication, a contract one layer breaks for another, and code in the wrong layer. A confirmed local fix needs no new independent round unless it introduces an uncovered contract, mechanism or failure path. A new notice or a changed PR body is not a code-review trigger.
-- **Probes.** Settle a suspicion with a probe per testing's Throwaway. Never start a service or test suite during read-only review.
-- **Browser evidence.** Inspect the existing preview, captures, console and relevant requests without changing page state. Give the owner the smallest missing browser action and observable result to check; the owner drives the browser and records it. A screenshot proves a visible state, not unobserved timing, persistence or release behavior.
-- **Test value.** Use testing to decide whether a permanent test protects a distinct plausible regression. Do not demand a new test for every finding when an inline probe or existing browser proof settles it.
-- **Variants.** After reproducing a defect, look for the same root cause in its other real callers. Broaden one dimension at a time and stop when unrelated hypotheses replace concrete evidence.
+| Severity | Meaning                                                                                                                                     |
+| -------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
+| P1       | Breaks a user or caller contract, loses data, misses a migration, leaks a secret, or a claim is false                                       |
+| P2       | Wrong owner, boundary or organization, rule violation, duplicated or dead code, or a mechanism, option or element the request does not need |
+| P3       | Naming, wording or style                                                                                                                    |
 
-Return the findings, or "Clean" with the covered scope. Each finding gives the path and line, the reaching input, the actual and required outcome, the consequence, the probe and the smallest fix.
+- **Classes.** Report a defect class once, with every instance's `path:line`; never repeat a finding an earlier round raised and the author answered.
+- **Rank honestly.** Never inflate a P3 to keep it alive; never pad a report with P3 to look thorough. Return P1 first; "Clean" with the covered scope when nothing reaches P2.
+- **Not findings:** taste without a rule, hypothetical inputs no caller sends, defects the branch neither made nor relies on, what lint reports outside legacy lists.
+- **Probe** a suspicion inline per engineering's Proof; never start a service or test suite in a read-only review.
 
-## Cleanup audit
+## Code
+
+- **Architecture first.** Before the lines, rebuild the change from the request alone: who owns each piece of state, the boundaries, the file and module organization, the data flow and the mechanism. The first pass usually gets this wrong, so attack it: wherever the change's shape differs from the simplest idiomatic one (fewer parts, the existing pattern, Effect's own building blocks), report it with that shape as the fix, even when every line is correct.
+- **Depth.** Read every hand-written changed line; for generated output, the generator change and a sample. Trace each contract through its real consumers, failure paths, concurrency and resource ownership against the merge base. A whole-file refactor keeps every behavior the file had.
+- **Simplicity.** Name each part the request does not need: a script, flag, option, wrapper, fallback, reimplemented library job, UI control or test, and each abstraction (helper, shared constant, generic, factory) that saves lines without lowering what a reader must hold. Name each block that duplicates code already in the repository, with both locations.
+- **Requirements.** Map each of the user's requirements to the hunk and the proof that meet it; a requirement with neither is a finding, even when no line changed for it.
+- **Production data.** A changed persisted shape without a migration that converts existing data is P1.
+- **Beyond the diff.** A contradiction with an unchanged file, a stale reference the change leaves, or a false assumption it rests on.
+- **Rounds.** Read the pushed head, never the author's working tree, which keeps changing: `gh pr diff <n>`, `glab mr diff <n>`, `git show <head>:<path>`. Judge the layer as one change; spend depth on commits since the last reviewed one. A stack overview reports what crosses layers: duplication, a contract one layer breaks for another, code in the wrong layer.
+- **Browser.** Inspect the existing preview, captures, console and requests without changing page state; name the smallest missing check for the author.
 
-Classify every changed file and hunk against the user's outcome and the reachable existing contracts. The author's plan does not authorize added scope. Default to removal, but preserve security, accessibility, required dependencies and useful regression protection:
+## Cleanup audit
 
-- **Revert:** unrelated formatting, lint-only rewrites, renames, reordered keys and files. Retain a required root fix and the repository's explicit cleanup scope. Do not weaken valid rules to retain obsolete code.
-- **Supersede:** features and versions that the final direction replaced, compatibility for unreleased versions, and capabilities that only a test or demo needed.
-- **Simplify:** the same behavior with less code or a clearer layout: files, folders and names that break the repository's layout, dead code, unused exports, duplicate logic, layered overrides, no-ops and workarounds.
-- **Cut:** anything the request does not need: features, function branches, files, libraries, settings, config values, UI elements, and machinery such as budgets, retries, caches, fallbacks, queues, daemons and dependency patches. Name what the user loses without each one; when he loses nothing, it goes.
-- **Keep:** a required outcome, dependency, reachable existing contract or useful regression proof. Quote the requirement or show the caller and the input that break without it.
+Classify every changed hunk against the request; the author's plan authorizes nothing. One row per item: path and lines, class, evidence, smallest change, what it breaks.
 
-Read every hand-written hunk; a sample is not an audit. Compare added, moved and renamed files and folders with `CODING_STANDARDS.md` and the closest sibling app or package. Near-empty files and helper files that mix roles are Simplify rows. Judge generated output through its generator and a sample. List each cast, suppression, filename exemption and file-wide disable that the change adds: a Simplify row with its typed alternative, or a Keep row for an exception that engineering allows. Return one row per item: the path and lines, the class, the evidence, the smallest change, its size and what it breaks.
+- **Revert:** unrelated formatting, renames, reordering.
+- **Supersede:** what the final direction replaced, compatibility for unreleased versions, capabilities only a test or demo needed.
+- **Simplify:** the same behavior with less code: dead code, unused exports, duplicate logic, layered overrides, near-empty files, each cast or suppression with its typed alternative.
+- **Cut:** what the request does not need: features, branches, files, libraries, settings, UI elements, budgets, retries, caches, fallbacks, queues, daemons. Name what the user loses; nothing lost, it goes.
+- **Keep:** a required outcome or reachable contract, with the caller that breaks without it.
 
-## Critique
+## Approach critique
 
-Challenge the outcome, the taste and the attempts so far, and do not defer to the author. Compare different mechanisms, including a smaller one. Test the strongest counterexample and the weakest assumption. Prefer a reversible combination of compatible strengths. Return the recommendation, its decisive reason and the observation that would change it.
+Compare different mechanisms, including a smaller one; test the strongest counterexample and the weakest assumption. Return the recommendation, its deciding reason and the observation that would change it.
 
 ## Instruction review
 
-Review the affected instructions as one system: prompts, skills, references, settings, repository rules and installed copies in the requested scope. Read every relevant file whole. Check each rule against the runtime and tool behavior it assumes, in source or a real session. Installation belongs to the configuration owner, not the reviewer.
+Read the affected prompts, skills, references and settings whole, as one system. Report contradictions, duplicated rules, a rule in the wrong owner, rules no agent can act on, text that changes no action, wording that over-explains what a frontier model infers from a leading word, stale names, paths and models. Check each rule against the real tool behavior it assumes. Rank by how much agent behavior each finding changes.
 
-Report contradictions, duplicate rules, rules that only one harness gets, rules that no agent can act on, stale names, paths and models, breaks of applicable repository language rules, text that does not change an agent's action, and eval claims without evidence. Return the findings ranked, each with the path and line, the probe and the smallest change.
+- **Missed or missing.** For a failure, read the transcript first: a skill that never loaded needs its trigger fixed; a clear rule that loaded and was ignored needs a better place or form, not more words.
+- **Form.** Wrong-shaped output gets a recipe or a good example, an omission a required slot, a conditional behavior an observable trigger; a prohibition alone only names the mistake.
+- **Settle** disputed wording by how agents behaved in real threads, not by debate.
 
 ## Body reader
 
-Read the published pull request as a reviewer who knows nothing else. Download the body and every embedded capture from the host, such as `glab api "projects/<project>/uploads/<secret>/<file>"`, and inspect each one. Compare them with the branch head and the source tickets. Report:
-
-- A risk that a tired reviewer misses: a migration, contract change or removed behavior the published body does not name.
-- A claim that a capture or the code contradicts.
-- A ticket requirement without proof.
-- A capture that is unreadable, ends before its outcome, or shows loading that is not the claim.
-- Each departure from the repository's publishing contract or the available delivery skill.
-
-Return each finding with the section, the evidence and the smallest fix.
+Read the published PR as a reviewer who knows nothing else: the body, every capture downloaded from the host, the branch head and the source tickets. Report a risk the body does not name (migration, contract, removed behavior), a claim the code or a capture contradicts, a ticket requirement without proof, and an unreadable capture.

package/skills/architecture/EVALS.md

@@ -1,21 +0,0 @@
-# Architecture evaluations
-
-## architecture
-
-### Task
-
-Let me import a folder of data files, see progress and stop without losing completed records. Choose the architecture before writing product code. Explain only the decisions I need to make.
-
-### Criteria
-
-Judge the mechanism and caller obligations, not the number of modules or diagrams.
-
-- Trace existing CLI, HTTP and browser consumers and preserve single-file behavior.
-- Keep persistence and cancellation in the existing service and its operation scope.
-- Reject an unnecessary job registry, detached writer, mirrored progress store and generic importer factory.
-- Give completion one observable meaning: the emitted record is durable.
-- Handle reachable read, decode and write failures without blanket retries or empty-success defaults.
-- Use a disposable experiment for an uncertain technical contract; decide an unresolved user outcome from exploration and show it beside the strongest alternative; ask no question.
-- Name a concrete contract before adding a boundary, dependency or background lifetime.
-
-Grade simplicity and preserved behavior separately. A written design does not prove its implementation. Keep integrated planning and steering evaluations separate from this selected-skill case.

package/skills/architecture/SKILL.md

@@ -1,39 +0,0 @@
----
-name: architecture
-description: 'Choose the smallest production mechanism, module boundaries, state owners and failure contracts. Use for new features, consequential refactors and reviews of architectural complexity; engineering owns syntax and implementation conventions.'
----
-
-# Architecture
-
-Start from a real caller and the required outcome, not a pattern or framework. Apply engineering to the implementation. A new abstraction must remove a concrete obligation from its callers.
-
-## Trace the operation
-
-Read the nearest working feature and every affected consumer. Trace one successful operation and its strongest reachable failure through the existing modules. Identify the authoritative state, write boundary, resource lifetime and observable completion signal. Preserve the existing contracts that the change reaches.
-
-Before code, settle these facts in the current plan, without creating another document:
-
-- The caller's input, output and ordering obligations.
-- One owner for each value, resource, side effect and failure.
-- The existing module that can own the operation.
-- The boundary where untrusted input becomes trusted data.
-- What remains durable after interruption, and how the caller knows.
-
-Settle technical mechanisms with source or a probe per testing's Throwaway. File layout, module boundaries, public interfaces and names follow engineering's Taste.
-
-## Choose the smallest mechanism
-
-- **Existing shape.** Extend the canonical example from engineering's Patterns before creating a service, module or dependency.
-- **Direct operation.** Prefer a function or existing service method. Add a service for a distinct capability or lifetime, not to rename a forwarded call. Add another backend only when a real consumer needs it.
-- **Authoritative state.** Derive values from their owner. Do not mirror server state, request state, caches or pending results in another store. A persisted value has one write boundary.
-- **Lifetime.** Keep finite request work in its request scope. A stream serves progressive results; it does not require a job system. Add background ownership only when work must survive the caller, with a real owner for stopping, recovery and completion.
-- **Failure.** Handle failures the caller can reach, and keep domain identity, causes and completed work through them. Never turn a failure into empty success.
-- **Retries.** For a contract that permits retry after an unknown write outcome, keep the request identity stable for one intent. Add no retry policy or idempotency machinery to operations that do not need that contract.
-- **Boundaries.** Split code when dependencies, invariants or lifetimes differ. Prefer a substantive module to a chain of forwarding files.
-- **Variations.** Use explicit variants for genuinely different behaviors. Do not add boolean combinations, a plugin registry, a generic configuration object or a universal factory for hypothetical callers.
-
-Compare a new mechanism with the direct existing-module version. Count new state owners, boundaries, dependencies and failure paths, not just lines. Keep the simpler version unless a concrete contract rules it out. Prove that contract with a question-sized experiment.
-
-## Challenge the design
-
-Try the strongest reachable counterexample: an interrupted write, repeated intent, stale response, overlapping caller or dependency failure. Check which owner preserves the invariant. Use testing to select evidence, not to turn every doubt into a permanent test. Do not defend an abstraction because it is already implemented: state what breaks without it, and remove it when nothing does.

package/skills/design/EVALS.md

@@ -1,46 +0,0 @@
-# design evaluations
-
-## design
-
-### Task
-
-Make importing records clear and comfortable on my iPhone, including progress, stopping and seeing what was kept. Show me the design before changing the service.
-
-### Criteria
-
-Judge the browser experience, not the amount of UI produced.
-
-- Use the existing import workspace and realistic record names.
-- Make idle, active, cancelled, completed and empty states understandable.
-- Keep completed records visible when the import stops; distinguish stop from undo.
-- Establish readable light and dark views at 390-point width, touch targets and keyboard access.
-- Show the representative journey early in the real host and start the backend change at once; revise only the part the user's report steers.
-- Remove redundant controls and status text; use interaction to explore a real consequence, not to navigate an explanation.
-
-Inspect every visible state and transition. Grade hierarchy, behavior and readability independently of engineering and proof-capture quality. The user judges the final variants.
-
-## overview-format
-
-### Task
-
-Give me a quick overview of these changes: Review moved into coding-standards; Architecture was added; open choices get an inline prototype beside the production code, with no approval wait; routine fixes need no prototype; proof uses inline probes before permanent tests. These instruction changes are local, not installed. There are no UI captures, measurements or interactive choices to show.
-
-### Criteria
-
-- Use a short Markdown table or list. Do not produce HTML, an image of the same rows, controls or a separate presentation app.
-- Keep every supplied distinction, including routine fixes and installation state, with the fewest words that remain clear.
-- Do not add an introduction or duplicate the overview in a summary.
-- Judge the delivered artifact, not an explanation of format selection. Leave native-run behavior unproved until the case runs.
-
-## animated-mechanism
-
-### Task
-
-Show why an importer must write a record before reporting progress. Show the record becoming durable, then the progress event, as a short automatic animation. Do not make me click. This is an illustrative explanation, not evidence from a real application.
-
-### Criteria
-
-- Use the animation to show the named record, durable storage and progress event in the correct causal order.
-- Keep the message understandable without controls, extra introductions or duplicated prose.
-- Distinguish illustration from application proof; inspect actual timing rather than inferring motion from a still.
-- HTML adds the requested animated mechanism; a styled list of phases alone does not meet the task.

package/skills/engineering/EVALS.md

@@ -1,34 +0,0 @@
-# engineering evaluations
-
-## engineering
-
-### Task
-
-Let me import a folder of data files, see progress and stop an import without losing completed records.
-
-### Criteria
-
-Judge the final patch and the full run, not task completion alone. Independent behavior proof must exercise nested folders, emitted progress, interruption after a completed record, durable completed records and unchanged single-file CLI and HTTP behavior. Write that proof outside the candidate's source and choose its driver from the candidate's documented interface, not a prescribed implementation.
-
-- Use appropriate Effect primitives and the existing package boundaries.
-- Keep both consumers on the shared service; remove the code, exports, configuration and docs the change supersedes.
-- Use no unnecessary wrappers, runtimes, dependencies, retries or compatibility branches.
-- Establish resource release and no further record writes after cancellation.
-- List each corrective edit required before you would accept the patch.
-
-Do not score agent-written test quality here; the testing case owns it.
-
-## pattern-change
-
-### Task
-
-From now on we call imported entries "rows", not "records". Change it.
-
-### Criteria
-
-Judge the final patch and the full run. The user did not list the places; the agent must find them.
-
-- Treat the request as a repository standard: change every visible term, route, identifier and document that names the old term, across the CLI, HTTP and browser consumers, in one change.
-- Find the consumers with a search, migrate each one and run the search again before completion; report any occurrence kept on purpose with its reason.
-- Keep behavior unchanged apart from the rename; add no alias, redirect or compatibility path.
-- List each corrective edit required before you would accept the patch. Passing behavior checks is a prerequisite, not the quality score. Report first-pass readiness and corrective edits from evidence, distinguishing deliberate failing tests and environment failures from implementation defects. Leave a fact unobserved when the trace cannot establish it.

package/skills/review/EVALS.md

@@ -1,24 +0,0 @@
-# Review evaluations
-
-These cases and criteria are drafts for discussion with the user, not approved acceptance thresholds.
-
-## review
-
-### Task
-
-Is this folder-import change ready for me to accept? Review the current diff without changing application code.
-
-### Criteria
-
-The starting repository contains the existing single-file importer and an uncommitted folder-import change. Judge the review against independently reproduced defects, not the number of findings.
-
-- Detect omitted nested files and progress emitted before durable writes.
-- Show the reaching input, observable consequence and smallest fix for each defect.
-- Keep findings limited to the changed behavior and its real consumers.
-- Do not flag preserved schema decoding, cause mapping or sequential stream consumption as defects.
-- Do not rewrite code, invent requirements or reverse settled decisions.
-- Keep the report readable and actionable; omit praise and process narration.
-- Reproduce suspicions with inline probes rather than adding permanent tests or private test seams.
-- Preserve independent validation, failure causes and existing caller contracts during cleanup.
-
-Record missed defects, false positives, unnecessary reads, tokens, elapsed time and corrective requests separately. The user judges whether the report supports acceptance. This case measures read-only code review, not implementation or PR-body formatting.

package/skills/testing/EVALS.md

@@ -1,22 +0,0 @@
-# testing evaluations
-
-## testing
-
-### Task
-
-Make me confident that stopping a folder import keeps completed records and releases its resources.
-
-### Criteria
-
-This case supplies the folder-import implementation. Judge the agent's tests separately from engineering changes.
-
-- Exercise observable persistence, streaming order, cancellation and resource ownership through real boundaries.
-- Synchronize on progress or a controlled dependency, not arbitrary sleeps.
-- Test the existing single-file contract and both consumers where the claim crosses them.
-- Prove the tests fail when progress is emitted before the write and when a detached writer continues after cancellation; mutation trials run outside the candidate checkout.
-- Cancel during an active file read through a controlled filesystem adapter and verify release. Do not mutate Effect's resource implementation or require an importer-owned finalizer that does not exist.
-- Reject tests of private implementation details, fabricated successes and redundant assertions.
-- Keep only distinct regression protection with a named wrong implementation and observable failure; do not reward new files or case count.
-- Use inline probes and real browser evidence for one-off questions without turning each observation into a permanent test.
-
-Report which defects each test detects and which remain uncovered. Do not reward test count or coverage percentage. Record merge readiness and effort separately.

package/skills/testing/SKILL.md

@@ -1,64 +0,0 @@
----
-name: testing
-description: 'Select and run black-box behavior proof for Effect apps and tools. Use when choosing, writing, reviewing or running tests; apply engineering to test code and keep exploratory proof question-sized.'
----
-
-# Testing
-
-**Scope.** Test behavior the changed code owns; a coverage count proves nothing.
-
-- **Worth it.** Retain a test only when it names owned behavior, a plausible wrong implementation, an independently known observable result and distinct protection. State what breaks without it. A green suite, coverage increase or extra case is not a reason to keep a test.
-- **Public interface.** Test exported Layers, services and functions through observable behavior, so a rewrite that keeps the contract keeps the tests green. The browser proves web UI components; the simulator proves native ones.
-- **Redundant.** Delete touched cases that only repeat dependency guarantees, constants, wording, removed behavior or a covered input. Keep boundary tests of the application's own validation, encoding or integration.
-- **Independent.** Take expected values from the contract or a worked example, never from the implementation. Use the smallest reachable fixture that tells the cases apart.
-- **Bugs.** Reproduce a bug before you fix it. For a hard bug, test one hypothesis per probe, remove the edits of a disproven hypothesis and rerun the original scenario. Keep a regression case when future changes can plausibly break its contractual behavior, in the existing test of the fixed code or a new case when none fits. An independently reproduced defect does not require a new test file.
-- **Throwaway.** Start with question-sized inline code, an existing test or a focused real-browser check. Run inline code against the public interface, real data or the installed artifact with the repository's runtime command, such as `vp node -e '<script>'` or `vp env exec bun -e '<script>'`, and verify that it loads the source and dependencies. Never create a test file, worktree or seam to answer one question. Delete the spike after it answers the question. Promote it only when its distinct regression protection meets Worth it; never add a private export or configurable production seam just for proof.
-- **Honest.** No wrong expectations or rule workarounds. Change assertions only for recorded behavior changes, and keep every still-relevant value.
-
-**Assertions.** Use one representative input per behavior, in its existing case. Share a helper only between cases that use it. Use @effect/vitest assertions for outputs and structured error identity. Replace dependencies through Layers or public parameters, never global or module mocks. Keep mutable state in its owning fixture.
-
-```ts
-// good — "test files only for the services/packages public interfaces"
-it.layer(Layer.provideMerge(Ledger.layer, NodeServices.layer))(test => {
-	test.effect('keeps the previous entries when the file is malformed', () => program)
-})
-assert.deepStrictEqual(customCodes(result.stdout), ['@deslop/coding-standards(no-typeof)'])
-assert.containsSubset(error, {_tag: 'SandboxUnavailable', cause: killed})
-Layer.succeed(OpenSandbox, openSandbox)
-// bad — "1 userful test is better than 1000 useless ones"
-it.effect('rejects an empty tag', () => run(ledger.add({tag: ''}))) // Schema.isNonEmpty already does
-// bad — "this test is useless, it doesn't test that the agent is working"
-it.effect('forwards the prompt', () => run(agent.prompt(message))) // wiring that only shows a call reaching a double
-additional?: {name: string; source: string}[] // a helper option one case needs
-it.effect('loads', () => pipe(program, Effect.provide(Ledger.layer))) // no owned behavior asserted
-assert.isTrue(Array.some(diagnostics, d => d.code === 'typescript(TS2456)')) // another tool's output
-expect(error).toMatchObject({_tag: 'SandboxUnavailable'}) // Vitest's expect
-assert.strictEqual(Array.flatMap(attioProvider.groups, group => group.actions).length, 75) // a pinned count
-```
-
-## Choose cases
-
-- **Contract.** Connect a reachable input to an observable output, so a plausible wrong implementation fails. Use no new harnesses. When behavior is uncertain, settle one reachable case with a focused check and a minimal implementation, then choose the next case from the findings. Never batch tests for an imagined implementation or require universal TDD.
-- **Branches.** Exercise the reachable distinctions: empty, duplicate, concurrent and dependency failure. Write no Cartesian product, and no random or repeated happy paths without a hypothesis.
-- **Failure.** Use `Effect.flip` for an expected failure and `Effect.exit` for both outcomes. Assert domain identity and preserved state and resources: no partial write, lost value, extra retry or leak. Wording or rejection alone is not enough, and incidental order is no assertion.
-- **Control.** Run the regression test against the unfixed implementation, and confirm that the intended assertion fails, not setup, imports or compilation. Before a refactor, cover the old behavior.
-- **Audit.** Delete a case that no plausible wrong implementation fails, such as an assertion on a constant placeholder. Remove duplicate and tautological cases in the touched scope, but retain independent protocol, package, validation, authorization and persistence contracts. Mock call counts do not prove an external boundary. Do not replace a useful test with a disposable script just to reduce the count.
-
-## Effect and fixtures
-
-- **Entrypoint.** Plain `it` tests sync and Promise functions. `it.effect(name, () => effect)` runs with virtual services and `it.live` with real ones; return the Effect, with no runner wrapper. `it.layer` caches its block context and exposes `effect`, not `live`; shared live layers use `{excludeTestServices: true}`. Check APIs and imports against the cloned source.
-- **Lifetime.** `it.effect` and `it.live` supply a Scope per case; `it.layer` acquisition belongs to its block. Use scoped platform resources and no redundant whole-case `Effect.scoped`. To assert cleanup, close the smaller operation scope before you inspect.
-- **Isolation.** Shared layers share mutable services, `TestClock` and `TestConsole`, and `Layer.fresh` does not reset cached context. Use distinct keys, a public reset or case-local fixtures. Cases pass alone and together.
-- **Clock.** Take `TestClock` and `TestConsole` from `effect/testing`. Fork, await a `Deferred` at the dependency boundary that carries the actual key or path, adjust time, then join; forking alone is not readiness. JavaScript timers, sockets and processes need live services.
-- **Concurrency.** Give the dependency an entered and release pair: await entry, start the competing action, release, then assert the contract. Set `Effect.all` concurrency for overlap. For cancellation, await acquisition, interrupt and await completion, and assert release at the owning dependency while an unrelated outer Scope stays open. Joining an interrupted fiber alone does not prove resource release. Never test primitives or incidental ordering.
-- **Boundary.** Double only dependencies outside the tested logic, through a Layer or a public parameter. A claim about an SDK, process, filesystem, HTTP, browser or package integration needs the real boundary, not mocks or spies.
-- **Artifacts.** Prove a public tool with real packing and declared dependencies, not source imports or stubs. Generate fixtures with the real generator after one representative input settles; never alter expected output to fit a bug.
-- **Platform.** `FileSystem.layerNoop` is not memory storage, and `HttpServer.layerServices` supplies no filesystem: use a platform Layer and scoped paths. `RpcTest` bypasses serialization, and `HttpApiTest` bypasses sockets but proves routing, encoding, middleware and decoding; neither proves deployment or an external integration.
-
-## Run and reconcile
-
-- **Run.** Use the documented test selectors, and confirm that they collect and run the intended cases. Zero collected tests, setup alone or exit code 0 alone prove nothing.
-- **Inventory.** Collect independent failures in one run instead of stopping at the first, and tell separate cases from repeated observations. Rerun a timed-out test once in isolation; a pass proves that run, not the cause. Never call a bypassed selector or a skipped operation flaky.
-- **Evidence.** Keep the first failure, exact command, execution count and exit status. Separate cause from hypothesis, product defect from setup failure, and a skipped criterion from a passing one. A source read or a green command never replaces a missing behavior check.
-- **Final proof.** Retain each claim's command or browser journey, result, source revision, input, dependencies and configuration. Reconcile required behavior on the final code: rerun proof whose relevant inputs changed and reuse proof whose inputs did not. A steer invalidates dependent claims, not every check or capture. Required final repository gates still run. Use the actual built preview for final browser proof when the repository provides one. A command named preview that runs development watchers does not prove the production build. Screenshots and video prove visible outcomes; execution through the public interface proves the rest.
-- **Visual proof.** Record one claim through the real application with matching input, action and outcome. Keep every meaningful step. A capture is stale once a component it shows changes. For a provider-event claim, trigger the real provider when an account exists; otherwise send a signed request. When only the user can do the provider-side step, prepare a guide.