{"id":89098,"plugin_id":"plugins_6af1b0d8273c8191afa2e0d45bcb4f66","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-11-10T12:10:08.774Z","digest":"5de5c4116136243811deff841991b733557b849c5f14b82abb11fe3e63d004ca","against":null,"payload":{"description":"Prevent, detect, and repair AI coding slop and dirty engineering in repositories. Use for planning features, writing code, changing tests, reviewing pull requests, refactoring, hardening CI, debugging regressions, or auditing agent-generated changes. Enforces behavioral contracts, focused diffs, test integrity, repo conventions, security boundaries, and evidence-based completion.","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":317},{"relative_path":"references/anti-pattern-catalog.md","size_in_bytes":33489},{"relative_path":"references/clean-room-recon.md","size_in_bytes":6893},{"relative_path":"references/engineering-judgment.md","size_in_bytes":6085},{"relative_path":"references/evaluation-cases.md","size_in_bytes":3219},{"relative_path":"references/evidence-and-sources.md","size_in_bytes":3658},{"relative_path":"references/google-sre-discipline.md","size_in_bytes":7809},{"relative_path":"references/pr-review.md","size_in_bytes":3377},{"relative_path":"references/security-and-operations.md","size_in_bytes":2790},{"relative_path":"references/test-integrity.md","size_in_bytes":4188}],"name":"anti-slop-engineering","skill_md_contents":"---\nname: anti-slop-engineering\ndescription: Prevent, detect, and repair AI coding slop and dirty engineering in repositories. Use for planning features, writing code, changing tests, reviewing pull requests, refactoring, hardening CI, debugging regressions, or auditing agent-generated changes. Enforces behavioral contracts, focused diffs, test integrity, repo conventions, security boundaries, and evidence-based completion.\nauthor: Mamdouh Aboammar <mamdouhfces1997@gmail.com>\nlicense: MIT\nmetadata:\n  version: \"1.6.0\"\n  focus: \"engineering-discipline\"\n  repository: \"https://github.com/imMamdouhaboammar/anti-slop-engineering\"\n---\n\n# Anti-Slop Engineering\n\n**Mission:** Deliver the smallest *coherent, correct, maintainable* change supported by independent evidence. Never trade contract integrity, security, or reviewability for a green CI badge. Enforce Google Site Reliability Engineering (SRE) principles: Simplicity (KISS), Single Source of Truth (DRY), Anti-Speculation (YAGNI), and Fixing Issues at Scale (Eliminating Toil). Incorporate clean-room Stop-That-Shit boundary interception, Senior Dev ladders, and high-performance Rust/Go microservices. This skill applies to human and AI-authored changes equally.\n\n## Operating priorities\n\n1. Explicit user requirements, repository architecture, security policy, and existing public contracts outrank aesthetic preferences.\n2. Preservation of authorized existing behavior outranks making a new implementation pass its own tests.\n3. Prove behavior before polishing style; fix correctness and security blockers before cosmetic issues.\n4. Minimize **unnecessary** complexity, not required tests, safety checks, or clarity. A short but incorrect solution fails.\n5. Do not declare a finding without file/line evidence and an impact story. Never invent tool results or test runs.\n6. Never change or approve unrelated code, tests, policies, dependencies, CI, or infra merely to make the current request pass.\n7. **Official boilerplate & installers over manual scaffolding:** For any greenfield project, service, framework, library, or SDK integration, agents MUST rely on the official CLI installer, starter boilerplate, or generator (e.g., `uv init`, `cargo init`, `bun create`, official SDK quickstarts). Never manually hand-roll ad-hoc scaffolding, arbitrary directory layouts, or loose config files by hand.\n8. **Strict latest stable versioning:** When installing, initializing, or introducing any new dependency, library, or SDK, strictly query the registry and pin the **latest stable version**. Never guess outdated versions from training memory or rely on obsolete templates.\n9. **Taste, Visual Restraint & Clean UI Microcopy:** Never clutter user interfaces with walls of text, repetitive explanations, or overcrowded navigation bars. Respect visual hierarchy, purposeful white space, and minimal, polished microcopy. Eliminate gratuitous widgets, stat pills, or icon clutter.\n10. **Zero Dev-Notes Leakage in User-Facing UI:** Never render internal developer instructions, agent reminders, mock disclaimers, or architecture apologies (`\"Note: In production...\"`, `\"Mock data displayed\"`, `\"TODO: Add auth\"`) into user-visible DOM/JSX. Keep internal technical context strictly in code comments or project design documents.\n11. **Documentation Restraint & Zero Speculative Docs:** Never generate unprompted documentation files, submission dossiers, reviewer packets, or platform guides (e.g. \"Publish to OpenAI ChatGPT Plugins\", fake marketplace submission dossiers, speculative deployment recipes). Never cite dead, deprecated, or hallucinated third-party submission portals (e.g. `platform.openai.com/plugins`). Keep documentation strictly factual, lean, and grounded in real, requested repository capabilities. Reject documentation file sprawl and ceremonial note callouts.\n12. **The Zero-Obviousness & Direct Payload Doctrine:** Strictly eliminate trivial syntax narration, tautological docstrings, patronizing UI microcopy, ceremonial documentation truisms, and affordance narration. All documentation, code, and interfaces must adhere to the **Direct Payload Invariant**: transition directly from domain headers into technical payloads (code, tables, media, schemas) with ZERO conversational preambles (\"The following table outlines...\"), ZERO affordance narration (\"click to play/expand/copy/scroll\", \"watch here without leaving the page\"), ZERO mechanical hand-holding (\"open your terminal\", \"save the file\"), and ZERO bilingual title-stacking or promotional buzzword inflation. Standard UI affordances and technical payloads speak for themselves; silence and clarity outrank noise.\n13. **Google Site Reliability Engineering (SRE) Discipline:** Enforce the four foundational Google SRE principles across all changes:\n    - **KISS (Simplicity as a prerequisite to reliability):** Keep cyclomatic nesting <=4 levels. Functions exceeding 80 lines must be decomposed into single-responsibility units. Reject pass-through wrapper chains that add no value.\n    - **DRY (Single source of truth):** Replicated invariants, duplicated validation patterns, or parallel error structures are reliability hazards. Consolidate into canonical modules.\n    - **YAGNI (Anti-speculative engineering):** Zero speculative parameters (`_unused_param`, `future_kwargs`), dead branches (`if False:`), or placeholder stubs. Build for active requirements only.\n    - **Fix Issues at Scale (Eliminating toil & distributed resilience):** Automate repetitive manual toil. Enforce exponential backoff with full jitter on all network retries to avoid retry storms. Never use `sleep()` as an async race band-aid. Bound concurrency and enforce idempotency on state-changing endpoints.\n14. **Clean-Room Senior Dev Ladder & SHIT Interception (Ponytail, STS, Boring Engineering):**\n    - Intercept the four SHIT hazards: Scope creep (`S`), Hypothetical hardening/unread companion hashes (`H`), Intent violation (`I`), and Task thrashing (`T`).\n    - Climb the Senior Dev Ladder before authoring code: (1) Does this need to exist? (2) Does it already exist in the codebase? (3) Does the stdlib/platform do it? (4) Does native runtime cover it? (5) Does an existing dependency solve it? (6) Can it be a direct expression? (7) Write only minimal, necessary, tested code.\n    - **Name the Built-in:** Before writing custom parsing, validation, or UUID/cloning utilities, name the platform built-in (`crypto.randomUUID()`, `URLSearchParams`, `structuredClone()`). Hand-rolling standard primitives is a defect.\n    - **Practical DRY 3-Point Barrier:** Shared utilities or abstractions are permitted only when appearing in >=2 real existing call-sites, when all call-sites require identical modifications upon change, and when the abstraction can be named without coordinating conjunctions (`and`, `or`).\n15. **Decision Guard before consequential commitments:** When the task proposes derived metrics, an architectural stack, infrastructure, persistence, or a difficult-to-reverse engineering decision, read [Decision Guard](skills/decision-guard/SKILL.md). Check direct evidence and independent alternatives before treating the proposed method as necessary. Never substitute the decision record's structural check for source verification.\n16. **Root-Fix Gate for scattered symptom patches:** When a local behavior change spreads through controllers, views, endpoints or multiple layers, read [Root-Fix Gate](skills/root-fix-gate/SKILL.md). Trace the owner of the domain invariant, compare a coherent source correction with consumer workarounds, and inspect actual change paths. Do not assume the model owns every rule or that few files prove safety.\n17. **Future-Scale Gate for irreversible foundations:** Before locking in a core runtime, public contract, persistence model, or platform boundary for a long-lived product, read [Future-Scale Gate](skills/future-scale-gate/SKILL.md). Establish credible future operating scenarios, assess reversal cost and run a bounded evolution proof. Design the cheap necessary foundation now; defer speculative infrastructure with measurable revisit triggers. Lack of a present bottleneck does not disprove future architectural constraints.\n18. **Paranoid Principal Architect for 10M scale & zero-trust:** When designing system architectures, generating backend/frontend code, refactoring critical paths, conducting adversarial security reviews, or diagnosing scale bottlenecks, race conditions, memory leaks, and EDoS vulnerabilities, read [Paranoid Principal Architect](skills/paranoid-principal-architect/SKILL.md). Enforce the 10,000,000 Concurrent Users Axiom and Active Battlefield Zero-Trust mindset. Reject happy-path assumptions, unbounded async loops, hot keys, client authority, and unparsed inputs from line one.\n\n## Activation / modes\n\nSelect the relevant mode and follow the same gates:\n\n- **BUILD:** new feature or behavior change. Baseline -> contract -> RED -> GREEN -> REFACTOR -> independent review -> evidence.\n- **FIX:** reproduce observed bug first, fix smallest root cause, prove regression tests hold.\n- **REVIEW:** read-only diff and repository-context audit; report findings with severity, evidence, and counterfactual.\n- **CLEANUP:** establish an observable behavior baseline, isolate pure refactors from feature changes, prove no drift.\n- **NOTED_SLOP:** codify newly observed AI slop into a diagnostic catalog pattern, agent directive, and automated diff guard heuristic (see [CONTRIBUTING.md](CONTRIBUTING.md)).\n- **DECIDE:** when premises, direct answers or long-term architecture choices are materially uncertain, follow [Decision Guard](skills/decision-guard/SKILL.md) before BUILD. Return to ordinary modes after a decision; skip the extra protocol for routine repairs.\n- **ROOT-FIX:** when a symptom attracts scattered fixes or ownership is uncertain, follow [Root-Fix Gate](skills/root-fix-gate/SKILL.md) to establish the change boundary, then resume BUILD/FIX with regression tests.\n- **FUTURE-SCALE:** when an architecture commitment would be expensive to reverse as the product evolves, follow [Future-Scale Gate](skills/future-scale-gate/SKILL.md). Skip routine reversible edits and avoid capacity theater.\n- **PARANOID-ARCHITECT:** when building or reviewing systems against 10M concurrent user load, adversarial traffic, race conditions, hot-key contention, or zero-trust boundaries, follow [Paranoid Principal Architect](skills/paranoid-principal-architect/SKILL.md).\n\nFor extensive audits, load [anti-pattern catalog](references/anti-pattern-catalog.md). For Google SRE discipline and distributed resilience patterns, load [google-sre-discipline](references/google-sre-discipline.md). For any test changes, load [test integrity policy](references/test-integrity.md). For a PR or merge request, load [PR review protocol](references/pr-review.md). For elevated permissions, sensitive code, network access, or deployment, load [security and execution boundaries](references/security-and-operations.md). For project-specific exceptions, load [judgment and exceptions](references/engineering-judgment.md). For community contributions, follow [contributor guidelines](CONTRIBUTING.md).\n\n## The seven gates\n\n### Gate 0: Discover; do not improvise the repo\n\n- Read root and scoped instructions (AGENTS.md, CLAUDE.md, contributing docs), task and acceptance criteria, package manifests, lockfiles, CI, and nearby implementation/tests.\n- Identify language/framework versions from the actual repo, not what is newest. Identify existing helpers, types, error patterns, transaction boundaries, observability, API contracts, and test commands.\n- Read relevant open issues/PRs when available to avoid duplicates or fighting in-flight changes. Do not require network access to proceed when unavailable.\n- Record working tree status; do not overwrite user changes, reset, stash, or modify unrelated files without authorization.\n- Run an appropriate baseline build/test if feasible; label any existing failure as baseline, not caused by this change.\n- For a derived-answer task, inspect existing direct sources before constructing proxies. For an architectural commitment, inspect the product's actual rendering, workload, operations and persistence needs instead of defaulting to a familiar provider bundle. Load `skills/decision-guard/SKILL.md` only when this uncertainty is material.\n- For a proposed cross-layer patch, identify the first incorrect boundary and trace writes/reads before editing consumers. Load `skills/root-fix-gate/SKILL.md` when the same symptom would otherwise be patched in several places.\n- For a foundational architectural commitment, classify credible future stresses and costly reversal points before using today's workload as an excuse to hard-wire the system. Load `skills/future-scale-gate/SKILL.md` only for consequential choices and verify an actual evolution path before claiming future readiness.\n- For new projects, services, components, or SDK integrations, identify the official installer, CLI generator, and canonical starter boilerplate before writing code. Do not manually assemble configurations or directory trees from memory. Never generate unprompted documentation files, submission dossiers, or speculative third-party platform guides.\n\n### Gate 1: Establish a change contract\n\nBefore editing, note: **what changes, what must not change, business invariants, external APIs, expected failures, data impacts, security implications, rollback plan, and proof requirements.** For a task without a formal spec, derive a provisional contract from source + existing tests + user request, label uncertainties, and choose a conservative implementation.\n\nCreate a tiny scope plan: target files, candidate reuse, test points, risk areas. Identify any migration, locking/concurrency, auth, and data retention impacts explicitly. Ask for approval only for material externally visible ambiguity or destructive action; otherwise proceed conservatively and report assumption.\n\n### Gate 2: Lock the baseline tests without freezing legitimate evolution\n\n- Inspect existing regression tests **before implementation**. Prefer independently specified expected outcomes.\n- On bug fixes, write a failing reproduction first where practical. On new behavior, write tests for the agreed contract before implementation where practical.\n- Existing assertions/fixtures/snapshots are protected: if a test fails after a change, investigate implementation/regression first. Never weaken assertions, rewrite golden values, remove coverage, mark skipped/xfail, or add exclusions merely to get green.\n- Existing tests *may* change when the approved behavior genuinely changes, an assertion was incorrect, or a justified test refactor is necessary. Explain **old contract -> new contract**, cite the authority, show before/after behavior, and obtain independent review on semantics.\n- Do not blindly ban test edits or insist on unit tests for every I/O interaction. Select unit/integration/contract/E2E based on risk. See [test integrity](references/test-integrity.md).\n\n### Gate 3: Implement with minimum justified complexity\n\n- **Official tooling over manual scaffolding:** When initializing an application, module, or SDK integration, invoke the official CLI installer / starter generator rather than manually typing out build configurations (`tsconfig.json`, `package.json`, `pyproject.toml`, Dockerfiles, etc.).\n- **Strict latest stable dependency pinning:** When adding new dependencies or SDKs, always query the package manager or registry to install the latest stable release (e.g. `bun add <pkg>@latest`, `uv add <pkg>`). Pin versions strictly in manifests and generate valid lockfiles; never rely on pre-cutoff memory.\n- **Frontend taste & zero dev-notes leakage:**\n  - Strip out all internal developer/agent annotations, reminders, or mock warnings (`\"TODO: Wire backend\"`, `\"Note: Mock data\"`, `\"Agent notice:\"`) from user-visible DOM/JSX.\n  - Practice visual restraint: prevent crowded navbars, multi-row icon spam, or redundant controls in headers. Maintain clean visual hierarchy, balanced padding, and purposeful negative space.\n  - Enforce concise microcopy: avoid walls of explanatory text, repetitive instructions for obvious user actions, and defensive disclaimers. Every string in the UI must be concise and production-grade.\n- **Anti-logorrhea in code & interfaces:** Avoid writing unnecessary boilerplate, sprawling repetitive wrappers, or comments that merely narrate obvious syntax. Never bloat code or copy just to feel comprehensive.\n- **Zero-obviousness & anti-truism:** Reject code comments that narrate obvious syntax (`// return response`, `// increment i`, `// check if null`), tautological docstrings that merely restate symbol names, patronizing UI microcopy under obvious inputs (`\"Please enter your email\"` under an Email field), and documentation padded with trivial prerequisite truisms (\"requires internet and keyboard\"). High engineering discipline favors silence over noise.\n- Modify the existing abstraction whenever it fits; do not add parallel services, helpers, frameworks, compatibility layers, or configurable interfaces without a current need.\n- Keep business logic separate from transport and presentation when supported by the architecture; avoid both god objects and needless micro-files.\n- Use existing dependencies and repo conventions. New dependency requires clear functionality, maintenance, license, security, and bundle/runtime case.\n- Maintain error semantics, resource cleanup, cancellation, idempotency, state isolation, data validation, correct authorization, transactions, and backwards compatibility where required.\n- Avoid broad formatting/restructuring in functional PRs; remove incidental scaffolding that adds no value. Do not delete working behavior to make the diff smaller.\n\n### Gate 4: Verify beyond green tests\n\n- Run targeted tests and impacted full-suite checks supported by repo; report commands and outcomes verbatim or as reproducible summaries.\n- Inspect changed tests against the baseline; manually verify independently expected outcomes. Test the old failure, the new behavior, negative paths, and nearby regressions.\n- Exercise boundary tests relevant to change: contract/integration, concurrency, migrations, browser flow, performance, security and accessibility where applicable. Prefer real integration evidence over test doubles at critical seams.\n- Treat test coverage, lint, snapshot updates, and static-scan results as *signals*, never proof. Use mutation tests for fragile business rules when available.\n- If tools/environment prevent verification, say **NOT VERIFIED**; list exact blockers and do not claim completion.\n\n### Gate 5: Audit the diff as a skeptical reviewer\n\nRun `git diff --check` and inspect `git diff --stat`, changed files, changed assertions, added dependencies, config, and documentation. Triage can be executed via high-performance native Rust/Go microservices or portable Python scripts:\n\n```bash\n# Native Rust Engine (SHIT Boundary Interceptor & Senior Dev Ladder):\nbunx anti-slop-engineering rust triage\nbunx anti-slop-engineering rust shit-check --diff patch.diff\n\n# Go High-Throughput SRE Engine (KISS nesting, DRY token window, Toil & Error Budget):\nbunx anti-slop-engineering toil audit\nbunx anti-slop-engineering toil stream\n\n# Zero-dependency Python Core Fallback:\npython scripts/diff_guard.py --base HEAD --json\npython scripts/sre_guard.py --base HEAD --strict --json\n\n# In-Flight Real-Time Action Execution Guard:\nbunx anti-slop-engineering exec status\nbunx anti-slop-engineering exec check-action --tool <tool> --args '<json>'\nbunx anti-slop-engineering cases\n```\n\nReplace `origin/main` with your actual target branch; if unavailable, compare with a known commit using `--base HEAD`. If new files are untracked, stage only intended files *when authorized*, then re-run; the tool warns that untracked contents are excluded. **Regex flags (including trivial comment narration, patronizing UI copy, speculative docs, dev notes, and SRE scale hazards) are candidates for investigation, not confirmed defects.** The tool neither runs tests nor performs SAST.\n\nAsk explicitly: Could a smaller design do the same thing (KISS)? Did I create two sources of truth (DRY)? Are all parameters and options actively used (YAGNI)? Will retries trigger thundering herds or retry storms under scale (SCALE)? Did I silently expand scope?\n\n### Gate 6: Evidence and release decision\n\nUse [PR review protocol](references/pr-review.md) and the report template at [RUN_REPORT_TEMPLATE](assets/RUN_REPORT_TEMPLATE.md).\n\n- **BLOCK:** demonstrated critical regression; authorization/security/privacy failure; disabled or falsified tests without approved change contract; broken build; destructive migration without safety plan.\n- **REWORK:** meaningful duplication, needless architecture, unjustified new dependency, test-only-for-implementation, unexplained contract drift, unreviewable mixed changes.\n- **REVIEW:** large coherent changes, cosmetic smells, static heuristics, deliberate test updates or exceptions requiring context.\n- **PASS:** requirements met with observable evidence; no unresolved BLOCK or REWORK, risks and exceptions documented. PASS is not a warranty.\n\nBefore proposing merge, report: intent, changed files, exact test evidence, baseline test delta, remaining uncertainty, findings, and decision. Do not merge, deploy, or alter protected settings without permission and applicable controls.\n\n## Non-negotiable anti-cheating rules\n\n- Do not change a test's expected output to match the observed buggy output unless the new output is explicitly authorized by product contract.\n- Do not delete, skip, xfail, downgrade, mock away, or suppress a failing test to conceal a failure.\n- Do not use fake logs, fabricated benchmarks, imagined browser screenshots, test results, or invented source references.\n- Do not weaken lint/type/security/branch protection/CI policies simply to achieve success.\n- Do not modify lockfiles, dependencies, formatting, codegen, database schemas, or test fixtures as collateral damage.\n- Do not replace a targeted fix with a full rewrite without evidence and scope approval.\n- Do not manually scaffold project skeletons or hand-stitch configuration files when official language, framework, or SDK installers and boilerplates are available.\n- Do not pin outdated, deprecated, or guessed dependency versions from model training memory; always resolve and enforce the latest stable version from the official registry.\n- Do not render developer notes, agent reminders, mock disclaimers, or architectural apologies into user-facing JSX/HTML views.\n- Do not overcrowd headers, navbars, or dashboards with uncurated icons, redundant buttons, or gratuitous widgets that lack visual hierarchy.\n- Do not bloat UI copy with walls of explanatory text, defensive disclaimers, or verbose narration of obvious UI controls.\n- Do not write trivial syntax-narration comments (e.g. `// return result`, `// increment counter`, `// check null`) or tautological docstrings that merely restate symbol names.\n- Do not add patronizing UI microcopy or obvious instructional labels underneath self-evident controls (e.g. `\"Please enter your email\"`, `\"Click here to submit\"`).\n- Do not pad documentation, READMEs, or setup guides with obvious truisms, trivial prerequisite lists, or tautological summaries.\n- Do not violate the Direct Payload Invariant: never write affordance narration (explaining how to click, expand, play, scroll, or copy standard controls), conversational preambles (\"The following section discusses...\"), bilingual title-stacking (e.g. `Term · الترجمة`), buzzword inflation (calling screencasts \"Live Interactive Demos\"), or mechanical hand-holding in documentation and code.\n- Do not generate speculative submission dossiers (e.g., `docs/*SUBMISSION*.md`, `docs/*DOSSIER*.md`) or invent publishing guides for unrequested third-party platforms.\n- Do not cite dead, deprecated, or hallucinated platform URLs (e.g., `platform.openai.com/plugins`).\n- Do not sprawl the repository with ceremonial markdown files or pad READMEs with marketing filler, fake prompt examples, or repetitive note callouts.\n- Do not use arbitrary `sleep()` or hardcoded delay loops as a synchronization band-aid for async races or flaky tests.\n- Do not retry failing network operations without exponential backoff and randomized full jitter.\n- Do not spawn unbounded parallel tasks, workers, or promises without explicit concurrency limiters or backpressure signals.\n- Do not swallow errors silently with empty `except: pass` or `catch {}` blocks without structured logging or metric counters.\n- Do not introduce speculative parameters (`_unused_param`, `future_kwargs`), dead feature toggles (`if False:`), or unreferenced extension points.\n- Do not duplicate domain invariants, validation rules, or error models across multiple modules; maintain a single authoritative source of truth.\n- Do not over-restrict legitimate design: duplication in readable tests can be preferable to an unreadable abstraction, and a larger implementation can be necessary for correct safety boundaries.\n\n## In-flight task directives and execution control\n\nApply the Stop Ladder to balance task responsibility and boundary enforcement:\n1. Understand current responsibility (explicit contract, affected callers, data migrations).\n2. Start with a direct solution (existing codebase helpers, platform built-ins, standard library).\n3. Expand only to close concrete gaps (supported inputs, real obligations).\n4. Judge defenses by their effect (retain effective protection, eliminate unneeded hashes or error swallowing).\n5. Verify the result and finish (no circular verification or redundant multi-agent loops).\n\nDirective syntax:\n```text\n$anti-slop [mode] [level] [files=...] [hash=...] [deps=...] [agents=N] -- [task]\n```\n\n- `mode`: `change` (default write), `review` (read-only), `answer` (read-only), `monitor` (read-only), `unconfirmed` (passive).\n- `level`: `guard` (enforcing block), `watch` (advisory warning), `off` (disabled).\n- `files=path1|path2|dir/**`: file boundary lock. Actions modifying paths outside this pattern are rejected with `PATH_OUTSIDE_CONTRACT`.\n- `hash=deny|ask|allow`: cryptographic checksum and hash policy.\n- `deps=deny|ask|allow`: dependency installation policy. When `deps=ask`, generates single-use runner tickets.\n- `agents=N`: concurrent subagent budget.\n\n## Deliverable contract\n\nFor each implementation/review, produce a concise report in this order: **Outcome; Scope; Behavior preserved/changed; Verification (commands + results); Findings with exact file/line; Test modifications with rationale; Risks/limitations; Merge recommendation.** If available, distinguish baseline failures from new failures. Use `NOT RUN` and `UNKNOWN` literally when applicable.\n\nThe [catalog](references/anti-pattern-catalog.md) is diagnostic, not an instruction to create work where there is no evidence of a problem.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}