@sha3/code 1.0.0

package/resources/ai/templates/skills/simplicity-audit/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: simplicity-audit
+description: Use this skill before and after non-trivial implementation work. It defines the required anti-complexity review that removes gratuitous files, layers, wrappers, and speculative configuration before finalizing code.
+---
+
+# Simplicity Audit
+
+## When To Use
+
+Use this skill before finalizing non-trivial implementation, especially when adding files, abstractions, classes, configuration, or transport layers.
+
+## Audit Pass
+
+Ask these questions in order:
+
+1. Can the same behavior be implemented with fewer files?
+2. Can a helper stay as a private or static method instead of becoming a new file?
+3. Does each abstraction solve a real current complexity problem?
+4. Does the design still look as direct as the template baseline?
+5. Did any new config key, type, or wrapper appear without a real consumer?
+
+## Remove First
+
+- speculative factories
+- wrapper services
+- unused option objects
+- premature `*.types.ts` files
+- helper files that should stay inside a class
+- transport or domain layers with only pass-through behavior
+- configuration added for unimplemented scenarios
+
+## Keep Only When Justified
+
+- role-specific extra files with a clear current responsibility
+- true cross-feature modules
+- validation schemas with non-trivial validation logic
+- public types that materially clarify the contract
+
+## Final Check
+
+Before finishing, compare the final structure to the simplest plausible design that still respects current boundaries. If the simpler design is still correct, the simpler design wins.

package/resources/ai/templates/skills/test-scope-selection/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: test-scope-selection
+description: Use this skill when code changes may affect behavior. It defines how to decide whether tests are required, which behavior deserves coverage, and what the minimum adequate test scope is.
+---
+
+# Test Scope Selection
+
+## When To Use
+
+Use this skill when implementation changes introduce meaningful logic, regression risk, public contract changes, or runtime behavior changes.
+
+## Decision Rules
+
+Add or update tests when the change affects:
+
+- observable behavior
+- public API output
+- transport contracts
+- configuration-driven behavior
+- branching logic
+- regression-prone workflows
+
+Do not add ad hoc tests for:
+
+- trivial renames
+- purely mechanical edits
+- formatting-only changes
+- behavior-neutral managed file regeneration
+
+## Coverage Selection
+
+Choose the smallest test set that proves the changed behavior:
+
+1. cover the main success path
+2. cover meaningful failure or edge behavior when it exists
+3. avoid implementation-detail assertions
+4. avoid duplicate tests that protect the same behavior
+
+## Transport Notes
+
+For HTTP changes, cover:
+
+- status code
+- response payload
+- validation failure when applicable
+- not-found or conflict behavior when applicable
+
+## Final Check
+
+If a behavior change would be risky to change again without a test, it should have a test.

package/resources/ai/templates/skills.index.template.md

@@ -0,0 +1,25 @@
+# Project Skills
+
+`ai/contract.json` remains the machine-readable source of truth and `AGENTS.md` remains the always-on policy layer.
+This file lists specialized workflows that should be loaded only when the task calls for them.
+
+## How To Use Skills
+
+1. Read `AGENTS.md`, `SKILLS.md`, and the relevant assistant adapter before implementation.
+2. Open only the `skills/<skill-name>/SKILL.md` file that matches the task.
+3. Load extra references only when that skill explicitly calls for them.
+4. If a skill conflicts with `ai/contract.json` or `AGENTS.md`, the higher-priority contract wins.
+
+## Default Workflow Skills
+
+- `init-workflow`: Use when implementing the first behavior in a freshly generated scaffold. Read `skills/init-workflow/SKILL.md`.
+- `refactor-workflow`: Use when refactoring an existing project or rebuilding legacy code on top of a regenerated scaffold. Read `skills/refactor-workflow/SKILL.md`.
+- `feature-shaping`: Use when mapping a requested behavior into the scaffold and choosing the minimum justified structure. Read `skills/feature-shaping/SKILL.md`.
+- `simplicity-audit`: Use before finalizing non-trivial changes to remove gratuitous complexity. Read `skills/simplicity-audit/SKILL.md`.
+- `change-synchronization`: Use when behavior changes may affect tests, exports, config, scripts, or documentation. Read `skills/change-synchronization/SKILL.md`.
+
+## Conditional Implementation Skills
+
+- `readme-authoring`: Use when creating or updating `README.md` so the package documentation matches the real public behavior. Read `skills/readme-authoring/SKILL.md`.
+- `test-scope-selection`: Use when deciding whether behavior changes need tests and what scope those tests should cover. Read `skills/test-scope-selection/SKILL.md`.
+- `http-api-conventions`: Use when a project exposes HTTP endpoints and route design, params, validation, and responses must follow the standard service conventions. Read `skills/http-api-conventions/SKILL.md`.

package/standards/architecture.md

@@ -0,0 +1,72 @@
+# Architecture Guide
+
+Architecture strictness is **moderate**.
+Simplicity policy is **minimal pragmatic (no speculative abstractions)**.
+
+This is not optional guidance. Simplicity is a mandatory constraint:
+
+- choose the smallest structure that works
+- do not add layers, indirection, wrappers, or extra files without present need
+- do not design for hypothetical future extension points
+- when in doubt, remove complexity instead of adding it
+- simplicity does not justify removing valid boundaries
+- generated templates are the canonical simplicity baseline; if a rule makes them worse, the rule must be revised before the template
+
+## Project Templates
+
+Two templates are supported:
+
+- `node-lib`
+- `node-service`
+
+## Default Layout
+
+Both templates SHOULD keep this baseline structure:
+
+- `src/` for implementation.
+- `test/` for automated tests.
+- `scripts/` for local automation scripts.
+- `docs/` for technical documentation.
+- `ai/` for generated assistant contract files.
+- `config/` for non-TypeScript configuration files (JSON/YAML/TOML) when needed.
+- Root tooling config files (`biome`, `tsconfig`) at project root.
+- `src/config.ts` for non-parameterized hardcoded configuration values.
+
+## Source Layout Standard
+
+`src/` SHOULD follow a feature-first layout:
+
+- `src/index.ts` as the entrypoint.
+- `src/<feature>/` for feature modules.
+- Feature folder names SHOULD be singular (for example: `src/user`, `src/invoice`, `src/billing`).
+
+Optional shared boundaries:
+
+- `src/app/` when composition/wiring becomes non-trivial.
+- `src/shared/` when cross-feature modules actually exist.
+
+Template-specific additions:
+
+- `node-lib`: MAY add `src/public/` and `src/internal/` to separate stable API from private implementation.
+- `node-service`: SHOULD keep transport concerns under `src/http/` (`routes`, `controllers`, `middleware`).
+- If a service needs to expose an HTTP API, it MUST use the latest published major/minor version of `hono` as the HTTP framework.
+
+Within each feature folder, files SHOULD be role-oriented and explicit (`*.service.ts`, `*.repository.ts`, `*.schema.ts`, `*.mapper.ts`, `*.helpers.ts`). Use `*.types.ts` only when shared feature types are substantial enough to deserve their own file. The domain base name SHOULD be singular (`invoice.service.ts`).
+Files inside `src/<feature>/` MUST expose exactly one public class unless the file is `*.types.ts`.
+
+## Boundary Rules
+
+- Keep feature modules cohesive.
+- Avoid cyclic dependencies.
+- Keep hardcoded application configuration centralized in `src/config.ts`.
+- `src/config.ts` MUST export a default object named `config` and consumers MUST import it as `import config from "./config.ts"`.
+- Structured output with meaningful size (for example documents, emails, pages, prompts, markdown, HTML, text reports, or similar artifacts) MUST live in dedicated template files rather than being assembled inline in application code.
+- Inline string construction is allowed only for very small fragments where a separate template file would add more noise than value.
+- Template rendering technology is an implementation choice: use the lightest approach that fits the case, from simple placeholder replacement to a dedicated templating library.
+- Prefer the smallest design that satisfies current requirements.
+- Do not introduce extra files, layers, or abstractions unless they reduce real current complexity.
+- Avoid speculative structure for future scenarios that are not implemented yet.
+- If two designs are both correct, the less abstract and less indirect design MUST win.
+- Respect cohesion and responsibility boundaries.
+- If code already has clear, justified boundaries, keep them. Do not remove them only to make the structure look simpler.
+- Generated README files MUST describe the real runtime or package behavior; they MUST NOT describe themselves as scaffold output outside `AI Workflow`.

package/standards/changelog-policy.md

@@ -0,0 +1,12 @@
+# Changelog Policy
+
+## Versioning
+
+Use semantic versioning for the published `@sha3/code` package.
+
+## Rules
+
+- Every release MUST include a concise changelog entry.
+- Breaking changes MUST document migration steps.
+- `npm run release:check` MUST pass before publishing.
+- Use `npm run release:publish` to publish from repository root.

package/standards/manifest.json

@@ -0,0 +1,36 @@
+{
+  "meta": { "version": "v1", "scope": "@sha3", "packageManager": "npm", "moduleSystem": "esm" },
+  "language": { "runtime": "node", "typescript": true, "target": "ES2022" },
+  "formatting": {
+    "formatter": "biome",
+    "lineLength": 160,
+    "semi": true,
+    "singleQuote": false,
+    "simpleCallbackStyle": "prefer_concise_when_biome_keeps_it_concise"
+  },
+  "naming": {
+    "files": "kebab-case",
+    "directories": "kebab-case",
+    "typescript": {
+      "classes": "PascalCase_nouns",
+      "types": "PascalCase",
+      "interfaces": "PascalCase",
+      "functions": "camelCase_verbs",
+      "methods": "camelCase_verbs",
+      "variables": "camelCase",
+      "booleans": "camelCase_with_is_has_can_should_prefix",
+      "constants": "camelCase",
+      "moduleConstants": "SCREAMING_SNAKE_CASE",
+      "acronyms": "lowercase_in_identifiers_except_well_known_id_url_http_json",
+      "forbiddenGenericNames": ["data", "obj", "tmp", "val", "thing", "helper", "utils", "common"]
+    }
+  },
+  "architecture": { "strictness": "moderate", "simplicity": "minimal_pragmatic_no_speculative_abstractions", "templates": ["node-lib", "node-service"] },
+  "testing": { "runner": "node-test-runner", "coverage": false, "testLocation": "test/" },
+  "tooling": {
+    "biomeConfig": "@sha3/code/biome",
+    "tsconfigPackage": "@sha3/code/tsconfig/node-lib.json",
+    "enforcement": "biome-plus-verify"
+  },
+  "ai": { "enabledByDefault": true, "assistants": ["codex", "cursor", "copilot", "windsurf"] }
+}

package/standards/readme.md

@@ -0,0 +1,56 @@
+# README Guide
+
+## Goal
+
+Every repository README MUST be clear, actionable, and visually structured.
+For libraries, README MUST be complete integration documentation because other LLMs will use it as source-of-truth.
+README MUST read like documentation written by the package maintainer for another engineer.
+Do not write README like a generated scaffold summary, code dump, or file inventory.
+
+## Mandatory Sections
+
+- Title and one-line value proposition.
+- TL;DR or Quick Start with copy/paste commands.
+- Why or motivation section that explains the concrete problem the package solves.
+- Main capabilities section that explains the primary things the package lets a consumer do.
+- Setup and usage examples.
+- Installation requirements and exact install command.
+- Public API reference (exports, parameters, return values, and behavior notes).
+- Examples section with runnable copy/paste examples.
+- Configuration reference (`src/config.ts` constants and impact).
+- Compatibility and constraints (runtime, module format, TypeScript expectations).
+- AI workflow section when the repository uses AI coding contracts.
+- Troubleshooting or FAQ.
+
+## Writing Rules
+
+- Start from the consumer perspective: why this package exists, when to use it, and what stable surface it offers.
+- README content MUST be written in English.
+- Write like the package maintainer talking to another engineer, not like a scaffold narrator.
+- Use concrete commands and expected execution order.
+- Avoid vague claims without implementation detail.
+- Keep headings and lists scannable.
+- Document every public export from `src/index.ts`.
+- If a public export is a class, document each public method with purpose, parameters, return value, and behavior notes.
+- Document configuration keys as user-facing controls, not just constant names.
+- Do not enumerate private methods, internal helpers, or implementation-only files unless they are necessary for consumers to operate the package.
+- Do not describe the project as "scaffolded", "generated", or "template" documentation in the README itself.
+- Do not describe the README itself, the scaffold, or the generation process outside the `AI Workflow` section.
+- Put practical examples before the exhaustive API reference where possible.
+- Use a structure inspired by high-quality package READMEs such as `ky`: fast value proposition, examples first, then detailed API reference.
+- Update README with every behavior or command change.
+
+## Verification Rubric
+
+- README MUST contain runnable `bash` or `ts` examples that match the actual public surface.
+- README MUST document every exported type/function/class and every public class method.
+- README MUST cover each top-level `config` key with user-facing impact.
+- README MUST avoid placeholder language, TODOs, and abstract filler.
+- A good README may use different wording than the template as long as it meets the same coverage and quality bar.
+
+## Quality Bar
+
+A top-tier README lets a new engineer understand and run the project in under 5 minutes without asking additional questions.
+For libraries, a top-tier README also lets another LLM integrate the library in a different codebase without opening source files or guessing public method behavior.
+A weak README sounds like a machine summarized the codebase.
+A strong README sounds like the author is explaining the package on purpose.

package/standards/schema.json

@@ -0,0 +1,124 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://sha3.dev/code/schema.json",
+  "title": "Code Standards Manifest",
+  "type": "object",
+  "additionalProperties": false,
+  "required": ["meta", "language", "formatting", "naming", "architecture", "testing", "tooling", "ai"],
+  "properties": {
+    "meta": {
+      "type": "object",
+      "additionalProperties": false,
+      "required": ["version", "scope", "packageManager", "moduleSystem"],
+      "properties": {
+        "version": { "type": "string", "pattern": "^v[0-9]+$" },
+        "scope": { "type": "string", "const": "@sha3" },
+        "packageManager": { "type": "string", "const": "npm" },
+        "moduleSystem": { "type": "string", "enum": ["esm"] }
+      }
+    },
+    "language": {
+      "type": "object",
+      "additionalProperties": false,
+      "required": ["runtime", "typescript", "target"],
+      "properties": { "runtime": { "type": "string", "const": "node" }, "typescript": { "type": "boolean" }, "target": { "type": "string" } }
+    },
+    "formatting": {
+      "type": "object",
+      "additionalProperties": false,
+      "required": ["formatter", "lineLength", "semi", "singleQuote", "simpleCallbackStyle"],
+      "properties": {
+        "formatter": { "type": "string", "const": "biome" },
+        "lineLength": { "type": "integer", "minimum": 80, "maximum": 200 },
+        "semi": { "type": "boolean" },
+        "singleQuote": { "type": "boolean" },
+        "simpleCallbackStyle": { "type": "string", "enum": ["prefer_concise_when_biome_keeps_it_concise"] }
+      }
+    },
+    "naming": {
+      "type": "object",
+      "additionalProperties": false,
+      "required": ["files", "directories", "typescript"],
+      "properties": {
+        "files": { "type": "string", "enum": ["kebab-case"] },
+        "directories": { "type": "string", "enum": ["kebab-case"] },
+        "typescript": {
+          "type": "object",
+          "additionalProperties": false,
+          "required": [
+            "classes",
+            "types",
+            "interfaces",
+            "functions",
+            "methods",
+            "variables",
+            "booleans",
+            "constants",
+            "moduleConstants",
+            "acronyms",
+            "forbiddenGenericNames"
+          ],
+          "properties": {
+            "classes": { "type": "string", "enum": ["PascalCase_nouns"] },
+            "types": { "type": "string", "enum": ["PascalCase"] },
+            "interfaces": { "type": "string", "enum": ["PascalCase"] },
+            "functions": { "type": "string", "enum": ["camelCase_verbs"] },
+            "methods": { "type": "string", "enum": ["camelCase_verbs"] },
+            "variables": { "type": "string", "enum": ["camelCase"] },
+            "booleans": { "type": "string", "enum": ["camelCase_with_is_has_can_should_prefix"] },
+            "constants": { "type": "string", "enum": ["camelCase"] },
+            "moduleConstants": { "type": "string", "enum": ["SCREAMING_SNAKE_CASE"] },
+            "acronyms": { "type": "string", "enum": ["lowercase_in_identifiers_except_well_known_id_url_http_json"] },
+            "forbiddenGenericNames": {
+              "type": "array",
+              "items": { "type": "string" },
+              "minItems": 8,
+              "maxItems": 8,
+              "uniqueItems": true,
+              "const": ["data", "obj", "tmp", "val", "thing", "helper", "utils", "common"]
+            }
+          }
+        }
+      }
+    },
+    "architecture": {
+      "type": "object",
+      "additionalProperties": false,
+      "required": ["strictness", "simplicity", "templates"],
+      "properties": {
+        "strictness": { "type": "string", "enum": ["moderate"] },
+        "simplicity": { "type": "string", "enum": ["minimal_pragmatic_no_speculative_abstractions"] },
+        "templates": { "type": "array", "items": { "type": "string", "enum": ["node-lib", "node-service"] }, "minItems": 2, "uniqueItems": true }
+      }
+    },
+    "testing": {
+      "type": "object",
+      "additionalProperties": false,
+      "required": ["runner", "coverage", "testLocation"],
+      "properties": {
+        "runner": { "type": "string", "const": "node-test-runner" },
+        "coverage": { "type": "boolean" },
+        "testLocation": { "type": "string", "enum": ["test/"] }
+      }
+    },
+    "tooling": {
+      "type": "object",
+      "additionalProperties": false,
+      "required": ["biomeConfig", "tsconfigPackage", "enforcement"],
+      "properties": {
+        "biomeConfig": { "type": "string", "const": "@sha3/code/biome" },
+        "tsconfigPackage": { "type": "string", "const": "@sha3/code/tsconfig/node-lib.json" },
+        "enforcement": { "type": "string", "enum": ["biome-plus-verify"] }
+      }
+    },
+    "ai": {
+      "type": "object",
+      "additionalProperties": false,
+      "required": ["enabledByDefault", "assistants"],
+      "properties": {
+        "enabledByDefault": { "type": "boolean" },
+        "assistants": { "type": "array", "items": { "type": "string", "enum": ["codex", "cursor", "copilot", "windsurf"] }, "minItems": 4, "uniqueItems": true }
+      }
+    }
+  }
+}

package/standards/style.md

@@ -0,0 +1,106 @@
+# Style Guide
+
+All code MUST follow the canonical rules in `standards/manifest.json`.
+
+## Formatting
+
+- Use Biome for formatting.
+- Biome is the sole authority for wrapping, quoting, spacing, and final visual layout.
+- Use a max line length of 160.
+- Let Biome decide the final line wrapping.
+- Prefer compact code, but do not force single-line layouts for constructs that Biome intentionally preserves as multiline.
+- `verify` MUST NOT enforce a visual code shape that Biome can legitimately rewrite.
+- Use semicolons.
+- Use double quotes for strings.
+
+## TypeScript
+
+- Use strict TypeScript mode.
+- Project implementation and tests MUST be TypeScript-only (`.ts`).
+- JavaScript source files (`.js`, `.mjs`, `.cjs`) are not allowed in `src/` or `test/`.
+- Simplicity is MANDATORY.
+- Always choose the simplest correct implementation that solves the current requirement.
+- Prefer fewer lines, fewer files, fewer layers, and fewer moving parts.
+- Do not introduce abstractions, wrappers, helper layers, option objects, factories, interfaces, or indirection unless they are justified by a real current need.
+- Avoid speculative design for possible future scenarios.
+- Simplicity MUST NOT come at the cost of cohesion or clear responsibility boundaries.
+- Do not remove justified modules, role-based files, or separations merely to make the structure smaller.
+- Prefer concise arrow functions for simple callbacks (for example in `map`, `filter`, `reduce`, `some`, `every`, `find`, `forEach`) when writing new code and when Biome already keeps that form.
+- Do not churn Biome-stable block-bodied callbacks solely to satisfy a style preference.
+- Heuristic rules MUST NOT require an exact code shape; they may only report risks with concrete evidence.
+- Avoid `any` unless there is no viable alternative.
+- Prefer explicit return types for exported functions.
+- Use type-only imports when possible.
+- Throw plain `Error` by default; use custom error types only when control flow depends on distinguishing them.
+- If a function/method needs many inputs, define a named `<FunctionName>Options` type and pass a single `options` parameter.
+- Always use braces in control flow (`if`, `else`, `for`, `while`, `do`).
+- In `src/`, business/domain logic MUST be implemented with classes by default.
+- Module-level exported functions in `src/` SHOULD be limited to minimal entrypoint/bootstrap wrappers.
+- Inside `src/<feature>/`, files MUST expose exactly one public class unless the file is `*.types.ts`.
+- If a file exposes a public class, helper logic MUST stay inside that class as private or static methods rather than module-scope functions.
+- Oversized classes MUST be split into smaller cohesive units with clear roles instead of accumulating into one monolithic file.
+- `src/config.ts` MUST export a default object named `config` and it MUST always be imported as `import config from ".../config.ts"`.
+
+## Standards Admission
+
+- No new rule may be added to `resources/ai/rule-catalog.json` without a normative source in `standards/*`.
+- Every new rule MUST declare implementation ownership, a positive fixture, a negative fixture, and an explicit non-overlap decision for `Biome` or other generic tooling.
+
+## Naming
+
+- Use English technical/domain terms for all identifiers.
+- All generated project content MUST be written in English, including source code comments, README files, documentation, AI instruction files, examples, and user-facing template text.
+- Use `kebab-case` for files and directories.
+- Feature folder names MUST be singular (`src/invoice`, `src/user`, `src/billing`).
+- Class names MUST be `PascalCase` nouns.
+- Type and interface names MUST be `PascalCase`.
+- Function and method names MUST be `camelCase` verbs.
+- Variable and property names MUST be `camelCase`.
+- Boolean identifiers MUST use `is*`, `has*`, `can*`, or `should*` prefixes.
+- Module-level constants MUST use `SCREAMING_SNAKE_CASE`.
+- Local constants (for example inside functions/methods) MUST use `camelCase`.
+- `src/config.ts` default export `config` and `src/logger.ts` default export `logger` are canonical naming exceptions to module-level constant naming.
+- Use lowercase acronyms in identifiers (`userId`, `statusUrl`, `httpServer`) except well-known compact tokens (`id`, `url`, `http`, `json`).
+- Prefer explicit role-based file names:
+  - `<feature>.service.ts` for business services
+  - `<feature>.controller.ts` for transport controllers
+  - `<feature>.repository.ts` for persistence adapters
+  - `<feature>.types.ts` for shared feature-level types and DTOs when keeping them inline would add noise
+  - `<feature>.helpers.ts` for extracted feature-local helper logic when it is justified as its own cohesive unit
+  - `<feature>.schema.ts` for validation schemas
+  - `<feature>.mapper.ts` for data transformation logic
+  - `<feature>.constants.ts` for constants
+- `<feature>` SHOULD be singular.
+- Do not create `*.types.ts` files for small or local types that are clearer in place.
+- Avoid ambiguous names such as `data`, `obj`, `tmp`, `val`, `thing`, `helper`, `utils`, `common`; use domain-specific names instead.
+
+## Class File Comment Blocks
+
+Class-oriented files MUST use 3-line JSDoc section markers in this exact order:
+
+```ts
+/**
+ * @section <block-name>
+ */
+```
+
+Required block names:
+
+1. `imports:externals`
+2. `imports:internals`
+3. `consts`
+4. `types`
+5. `class`
+6. `private:attributes`
+7. `protected:attributes`
+8. `public:properties`
+9. `constructor`
+10. `static:properties`
+11. `factory`
+12. `private:methods`
+13. `protected:methods`
+14. `public:methods`
+15. `static:methods`
+
+Section blocks without content MUST be omitted.
+`class` MUST appear immediately before the exported class declaration and marks the start of the class body.

package/standards/testing.md

@@ -0,0 +1,20 @@
+# Testing Guide
+
+Projects MUST use the Node test runner.
+
+## Location
+
+- Store tests under `test/`.
+- Use `*.test.ts` naming only.
+
+## Commands
+
+- `npm run test` MUST execute all automated tests.
+- `npm run check` MUST include test execution.
+
+## Assertions
+
+- Prefer `node:assert/strict`.
+- Keep tests deterministic and isolated.
+- Add or update tests when a change introduces meaningful logic, regression risk, or critical behavior that warrants automated coverage.
+- Do not create ad hoc tests for trivial, mechanical, or low-risk changes with no meaningful behavior to protect.

package/standards/tooling.md

@@ -0,0 +1,38 @@
+# Tooling Guide
+
+All new projects MUST use this package and its subpath exports:
+
+- `@sha3/code/biome`
+- `@sha3/code/tsconfig/node-lib.json` or `node-service.json`
+
+## Behavioral Policy
+
+In addition to tooling, each generated project MUST include profile-driven AI instructions:
+
+- `AGENTS.md` generated from the active style profile
+- `ai/contract.json` as the machine-readable contract
+- optional assistant adapters in `ai/*.md`
+
+The generated contract files are the top local AI coding contract.
+When generated instructions conflict with existing repository code, the generated `@sha3/code` conventions MUST win.
+All generated artifacts MUST be written in English, including `AGENTS.md`, `ai/contract.json` string content, assistant adapter files, README files, docs, examples, and template-generated user-facing text.
+
+## Enforcement
+
+Enforcement is local and strict.
+
+Required scripts:
+
+- `npm run standards:check`
+- `npm run check`
+- `npm run fix`
+- `npm run lint`
+- `npm run format:check`
+- `npm run typecheck` (MUST fail on any TypeScript error)
+- `npm run test`
+
+`npm run standards:check` MUST execute `code-standards verify`.
+Default verification fails only on `error` severity; `--strict` also fails on `warning`.
+`npm run lint` and `npm run format:*` MUST be backed by Biome.
+
+No remote CI is required for v1.

package/templates/node-lib/.biomeignore

@@ -0,0 +1,10 @@
+node_modules
+dist
+coverage
+.code-standards
+AGENTS.md
+PROMPT.md
+SKILLS.md
+ai
+prompts
+skills

package/templates/node-lib/.vscode/extensions.json

@@ -0,0 +1 @@
+{ "recommendations": ["biomejs.biome"], "unwantedRecommendations": ["dbaeumer.vscode-eslint", "esbenp.prettier-vscode", "rvest.vs-code-prettier-eslint"] }

package/templates/node-lib/.vscode/settings.json

@@ -0,0 +1,9 @@
+{
+  "editor.formatOnSave": true,
+  "editor.formatOnSaveMode": "file",
+  "editor.defaultFormatter": "biomejs.biome",
+  "[typescript]": { "editor.defaultFormatter": "biomejs.biome", "editor.formatOnSave": true },
+  "[javascript]": { "editor.defaultFormatter": "biomejs.biome", "editor.formatOnSave": true },
+  "[json]": { "editor.defaultFormatter": "biomejs.biome", "editor.formatOnSave": true },
+  "[jsonc]": { "editor.defaultFormatter": "biomejs.biome", "editor.formatOnSave": true }
+}