code-standards git:20261007.7cb691bA

Immutable. This exact content never changes and is served at /api/v1/blob/72b6c867e7064283.

---
description: "Code quality gates, tool discipline, package management, and browser verification for software engineering tasks."
globs: ["*.ts", "*.tsx", "*.js", "*.jsx", "*.py", "*.go", "*.rs", "*.java", "*.rb", "*.swift", "*.kt"]
alwaysApply: false
---

## Documentation Lookups

Verify consequential assumptions about library, framework, or SDK behavior against current authoritative documentation for the relevant version. Use Context7 when available; see `content/references/code-standards-detail.md` §Documentation Lookups when investigating or implementing such behavior.

## Tool Discipline

Prefer suitable dedicated tools when available; use shell tools when they are unavailable or do not cover the task. Choose efficient output and measure cost before adopting new tools. Read `content/references/code-standards-detail.md` §Tool Discipline when choosing search tools or evaluating tool integrations.

## Module Manifests

Non-trivial source files (exported symbols consumed elsewhere, over ~50 lines of logic, or side effects) are encouraged to carry a manifest header. Read `content/rules/module-manifest.md` for fields and exemptions when creating or substantially modifying one. Skeptic reports manifest gaps as **Minor**.

## DRY and Abstraction

Reuse established helpers and patterns when suitable. Extract shared logic when it improves clarity or maintenance; avoid abstractions built for hypothetical requirements. Review consequential duplication and unnecessary abstraction, and explain consequential exceptions in the output. Mere occurrence count, a single caller, or export status does not establish a defect. Skeptic findings require concrete impact and follow the general severity classification.

## Code Quality Gates

After modifying code, run applicable project lint, typecheck, and test commands; all must pass with zero errors before completion. Greenfield projects start with zero warnings. In existing projects, introduce no new warnings and report pre-existing issues to the user.

Do not suppress or disable checks to pass gates. Suppression comments (`@ts-ignore`, `noqa`, etc.) require explicit user approval. For new projects via `/ds-init-project`, set up pre-commit hooks (husky + lint-staged for JS/TS, pre-commit for Python). If an existing project lacks tooling, run available checks and recommend setup.

When implementing or modifying code, read `content/references/code-standards-detail.md` §Per-Language Strict Defaults, §Browser Verification, and §Discovery-Based Check Discipline for language defaults, browser checks, and hard-failing empty discovery.

## Package Management

When adding or upgrading dependencies, or diagnosing an outdated dependency bug, read `content/references/code-standards-detail.md` §Package Management for version resolution, existing constraints, and the upgrade-before-workaround policy.