@sha3/code 1.0.0

package/resources/ai/templates/rules/class-first.md

@@ -0,0 +1,45 @@
+### Class-First Design (MUST)
+
+- New business/domain logic MUST be modeled with classes by default.
+- Inside feature folders, only `*.types.ts` files may expose non-class exports.
+- Feature files in `src/<feature>/` MUST expose exactly one public class.
+- Exceptions for exported functions are limited to minimal entrypoint/bootstrap wrappers.
+- Each class MUST use constructor injection for dependencies.
+- A source file MUST expose one public class.
+- Mutable shared state MUST be avoided; prefer `readonly` fields and deterministic methods.
+- Class-oriented files MUST use this exact 3-line format for every section they declare:
+  - `/**`
+  - ` * @section <block-name>`
+  - ` */`
+- Required section block names (in order, and this order is mandatory when those blocks are present):
+  - `imports:externals`
+  - `imports:internals`
+  - `consts`
+  - `types`
+  - `class`
+  - `private:attributes`
+  - `protected:attributes`
+  - `public:properties`
+  - `constructor`
+  - `static:properties`
+  - `factory`
+  - `private:methods`
+  - `protected:methods`
+  - `public:methods`
+  - `static:methods`
+- Section blocks without class members MUST be omitted.
+- `class` MUST appear immediately before the exported class declaration and marks the start of that class.
+- `factory` MUST only contain methods that create and return instances of the same class.
+- `@section class` MUST have no intervening comments of any kind before `export class`.
+- When class-level documentation is needed, place it above the `@section class` block or document the constructor/public methods instead of inserting comments between the marker and the class declaration.
+
+Good example:
+
+- `ai/examples/rules/class-first-good.ts`
+- `ai/examples/rules/constructor-good.ts`
+- `ai/examples/demo/src/invoice/invoice.service.ts`
+
+Bad example:
+
+- `ai/examples/rules/class-first-bad.ts`
+- `ai/examples/rules/constructor-bad.ts`

package/resources/ai/templates/rules/control-flow.md

@@ -0,0 +1,13 @@
+### Control Flow Braces (MUST)
+
+- `if`, `else if`, `else`, `for`, `while`, and `do` blocks MUST always use braces.
+- Single-line `if` statements without braces are forbidden.
+- This rule applies even when the body has one statement.
+
+Good example:
+
+- `ai/examples/rules/control-flow-good.ts`
+
+Bad example:
+
+- `ai/examples/rules/control-flow-bad.ts`

package/resources/ai/templates/rules/errors.md

@@ -0,0 +1,18 @@
+### Error Handling (MUST)
+
+- Throw plain `Error` by default.
+- Introduce custom error types only when other code must distinguish failure kinds.
+- Do not add error classes or hierarchies without a real consumer.
+- Errors MUST be thrown and handled at clear application boundaries.
+- Silent catch blocks are forbidden.
+- `no-silent-catch` treats `throw`, `console.warn(...)`, `console.error(...)`, and promise-style `.catch(...)` handling as reporting/handling signals.
+- `console.debug(...)` does not satisfy `no-silent-catch`.
+- Error messages MUST include actionable context.
+
+Good example:
+
+- `ai/examples/rules/errors-good.ts`
+
+Bad example:
+
+- `ai/examples/rules/errors-bad.ts`

package/resources/ai/templates/rules/functions.md

@@ -0,0 +1,29 @@
+### Function Structure (MUST)
+
+- Functions and methods SHOULD stay under 30 lines.
+- Functions MUST implement one responsibility.
+- Long functions MUST be split into private helper methods.
+- In class-oriented feature files, helper logic MUST live inside the class as private or static methods rather than module-scope functions.
+- If a class grows too large, split it into smaller cohesive units with explicit roles instead of keeping one oversized class file.
+- Implementations MUST prefer the least complex control flow and the fewest necessary steps.
+- Avoid ceremony and indirection when a direct implementation remains clear and correct.
+- Prefer concise arrow callbacks (for example in `map`, `filter`, `reduce`, `some`, `every`, `find`, `forEach`) when writing new code.
+- Do not rewrite block-bodied callbacks that Biome already preserves solely for stylistic compactness.
+- Types MUST be preferred over interfaces for local modeling unless a public contract requires an interface.
+- New implementation and test files MUST be `.ts`.
+- JavaScript source files (`.js`, `.mjs`, `.cjs`) are not allowed in `src/` or `test/`.
+- Feature filenames MUST be domain-specific and role-specific (for example: `invoice.service.ts`, `invoice.repository.ts`, `invoice.helpers.ts`).
+- 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.
+- Exported schema-like values MUST use `camelCase` or `PascalCase` names.
+- Let Biome decide the final line wrapping. Prefer compact code, but do not force single-line layouts that the formatter preserves as multiline.
+- If a function/method needs many inputs, define a named `<FunctionName>Options` type and pass one `options` parameter.
+
+Good example:
+
+- `ai/examples/rules/functions-good.ts`
+
+Bad example:
+
+- `ai/examples/rules/functions-bad.ts`

package/resources/ai/templates/rules/naming.md

@@ -0,0 +1,13 @@
+### Identifier Naming Policy (MUST)
+
+- Identifiers MUST use English technical/domain terms.
+- Classes MUST use `PascalCase` nouns.
+- Types and interfaces MUST use `PascalCase`.
+- Functions and methods MUST use `camelCase` verbs.
+- Variables and properties MUST use `camelCase`.
+- Boolean identifiers MUST use `is*`, `has*`, `can*`, or `should*`.
+- 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.
+- Exported schema-like values MUST use `camelCase` or `PascalCase`.
+- Generic names are forbidden for new code (`data`, `obj`, `tmp`, `val`, `thing`, `helper`, `utils`, `common`).

package/resources/ai/templates/rules/readme.md

@@ -0,0 +1,36 @@
+### README Quality Standard (MUST)
+
+When creating or updating `README.md`, output MUST be top-tier and production-quality.
+
+Mandatory requirements:
+
+- README MUST clearly explain: what the project does, why it exists, and how to use it in under 60 seconds.
+- README MUST include practical copy/paste examples that are runnable.
+- README MUST include a fast path (`TL;DR` or `Quick Start`) and an in-depth reference section.
+- README MUST include a `Why` or `Benefits` section with concrete value, not vague marketing language.
+- For libraries, README MUST be complete integration documentation for external teams and LLM agents.
+- README MUST include a public API reference section with exported members and behavior expectations.
+- README MUST document every public export from `src/index.ts`.
+- If a public export is a class, README MUST document each public method with purpose, return value, and behavior notes.
+- README MUST include a configuration reference section (`src/config.ts`) with meaning of each constant.
+- README MUST include compatibility constraints (runtime, ESM/CJS expectations, TypeScript assumptions).
+- README MUST include a section for AI usage (how to instruct assistants to follow local standards).
+- README MUST avoid vague marketing language and focus on actionable guidance.
+- README MUST be visually structured with clean headings, concise lists, and code blocks.
+- README MUST look like serious package documentation, not like a scaffold placeholder.
+- README SHOULD follow a structure inspired by high-quality package READMEs such as `ky`: short value proposition, practical examples first, exhaustive API reference after.
+- README MUST be updated whenever behavior, commands, or setup steps change.
+
+Good example characteristics:
+
+- Starts with immediate value and one-command quick start.
+- Shows exact commands and expected flow.
+- Includes public API and method-level behavior without forcing reader to inspect source files.
+- Includes troubleshooting or FAQ for common confusion points.
+
+Bad example characteristics:
+
+- Only describes high-level ideas.
+- Missing runnable commands.
+- Forces reader to guess execution order.
+- Mentions a class exists without documenting its public methods.

package/resources/ai/templates/rules/returns.md

@@ -0,0 +1,13 @@
+### Return Policy (MUST)
+
+- Every function or method MUST have a single `return` statement.
+- Early returns are not allowed.
+- Conditional paths MUST assign to a local result variable and return once.
+
+Good example:
+
+- `ai/examples/rules/returns-good.ts`
+
+Bad example:
+
+- `ai/examples/rules/returns-bad.ts`

package/resources/ai/templates/rules/testing.md

@@ -0,0 +1,18 @@
+### Testing and Comments (MUST)
+
+- 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.
+- Tests MUST validate behavior, not implementation details.
+- Test files MUST be TypeScript (`*.test.ts`).
+- TypeScript validation MUST pass with zero type errors.
+- Any TypeScript error found by `npm run check` MUST be fixed in code; disabling strictness or adding ignore directives to bypass type errors is forbidden.
+- Comments MUST be explicit and extensive when logic is non-trivial.
+- Async workflows MUST use `async/await` style only.
+
+Good example:
+
+- `ai/examples/rules/testing-good.ts`
+
+Bad example:
+
+- `ai/examples/rules/testing-bad.ts`

package/resources/ai/templates/rules.project.template.md

@@ -0,0 +1,66 @@
+# Project Rules
+
+Read this file together with `AGENTS.md` and `ai/contract.json` before making implementation changes.
+
+## Core Rules
+
+- Treat `ai/contract.json` as the machine-readable source of truth.
+- Treat `AGENTS.md` as blocking local policy.
+- Treat `SKILLS.md` and `skills/*` as specialized workflow guidance that applies when the task matches that workflow.
+- Keep managed files read-only unless the user explicitly requests a standards update.
+- Managed files are ignored by Biome by default; do not remove those ignores just to lint contract or prompt artifacts during feature work.
+- Run `npm run check` yourself before finishing and fix any failures before you stop.
+- Fix every `error`, review every `warning`, and report every `audit` item.
+
+## Simplicity
+
+- Choose the simplest correct design for the current requirement.
+- Do not add speculative abstractions, helper layers, wrappers, or extension points without immediate need.
+- Do not use simplicity as a reason to remove valid responsibility boundaries.
+
+## Compactness
+
+- Let Biome decide the final line wrapping.
+- Prefer compact code when writing or refactoring, but do not force single-line objects, callbacks, or other constructs that Biome keeps multiline.
+- Do not split code into multiple lines just because it is “safer”, and do not manually collapse formatter-preserved multiline layouts.
+- `verify` must not be treated as authority over code layout when Biome can rewrite that layout.
+
+## Simple Callbacks
+
+- Prefer concise arrow callbacks in `map`, `filter`, `reduce`, `some`, `every`, `find`, and `forEach` when writing new code.
+- Do not rewrite Biome-stable block-bodied callbacks solely to satisfy a style preference.
+
+## Errors
+
+- Throw plain `Error` by default.
+- Use custom error types only when other code must distinguish failure kinds.
+- Do not add error hierarchies without a real consumer.
+
+## Transport Pragmatism
+
+- `single-return` stays strict across `src/` except for `src/http/**`.
+- In `src/http/**`, prefer the clearest handler flow for validation, auth, and response branching, including early returns when they reduce nesting.
+
+## Type Files
+
+- Keep small or local types close to the code that uses them.
+- Create `*.types.ts` only when shared feature types are substantial enough to justify a dedicated file.
+
+## Feature Classes
+
+- Inside `src/<feature>/`, files MUST expose exactly one public class unless the file is `*.types.ts`.
+- Do not implement feature modules as exported function collections.
+- If a file exposes a public class, helper logic MUST stay inside that class as private or static methods instead of module-scope functions.
+- Large classes MUST be decomposed into smaller cohesive units before they become monolithic files.
+
+## Active Deterministic Rules
+
+{{deterministicRules}}
+
+## Active Heuristic Rules
+
+{{heuristicRules}}
+
+## Active Audit Rules
+
+{{auditRules}}

package/resources/ai/templates/skills/change-synchronization/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: change-synchronization
+description: Use this skill when behavior, exports, config, runtime commands, or HTTP contracts change. It defines the affected-surfaces review required to keep code, tests, README, exports, and config in sync.
+---
+
+# Change Synchronization
+
+## When To Use
+
+Use this skill whenever behavior changes in a way that may affect exports, tests, configuration, commands, or documentation.
+
+## Affected Surfaces
+
+Review each of these before finalizing:
+
+- `src/index.ts`
+- `src/config.ts`
+- `README.md`
+- `test/`
+- `package.json` scripts when runtime behavior changed
+- `src/http/` and `## HTTP API` when transport behavior changed
+
+## Workflow
+
+1. Identify the behavior change.
+2. List the public and operational surfaces affected by that change.
+3. Update tests, exports, docs, and config in the same pass as the implementation.
+4. Re-check that examples, payloads, method names, and commands match the final code.
+
+## Final Checklist
+
+- exported surface matches real public behavior
+- tests cover the changed behavior where warranted
+- README examples match the current package surface
+- configuration documentation matches real runtime keys
+- HTTP documentation matches current routes and payloads
+
+## Prohibited Actions
+
+- Do not change behavior and defer docs or tests “for later”.
+- Do not leave README examples or API sections on stale scaffold behavior.
+- Do not add config keys without documenting their user-facing impact.

package/resources/ai/templates/skills/feature-shaping/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: feature-shaping
+description: Use this skill when mapping a requested behavior into the scaffold. It defines how to choose the canonical feature boundary, file set, and public surface while rejecting unnecessary layers and files.
+---
+
+# Feature Shaping
+
+## When To Use
+
+Use this skill when adding a feature, creating a new module or service, or deciding whether work belongs in an existing feature folder or a new one.
+
+## Read First
+
+- `AGENTS.md`
+- `SKILLS.md`
+- `ai/contract.json`
+- `ai/rules.md`
+- `src/index.ts`
+- `src/config.ts`
+
+## Workflow
+
+1. Identify the behavior being added and the public impact it creates.
+2. Decide whether the behavior belongs in an existing feature or a new feature folder.
+3. Choose the smallest file set that can hold the change cleanly.
+4. Place logic in the canonical boundary:
+   - `src/<feature>/` for feature code
+   - `src/app/` only for justified composition
+   - `src/http/` only for transport concerns
+   - `src/shared/` only for real cross-feature reuse
+5. Confirm that the planned structure is no more complex than the template baseline for the same requirement.
+
+## Core Rules
+
+- Prefer extending an existing cohesive feature over creating a new boundary.
+- Add new files only when the current requirement justifies them.
+- Keep business logic out of transport adapters.
+- Define the intended public API impact before implementation, even if that impact is “none”.
+
+## Prohibited Actions
+
+- Do not create helper, wrapper, factory, repository, mapper, schema, or shared files by default.
+- Do not create `src/app/` or `src/shared/` for hypothetical future reuse.
+- Do not split one cohesive behavior across multiple files for aesthetics alone.
+- Do not let feature boundaries follow implementation accidents instead of domain meaning.

package/resources/ai/templates/skills/http-api-conventions/SKILL.md

@@ -0,0 +1,171 @@
+---
+name: http-api-conventions
+description: Use this skill when a project exposes HTTP endpoints. It defines the standard route design, parameter naming, validation, response shapes, status codes, and README/test expectations for scaffolded HTTP APIs.
+---
+
+# HTTP API Conventions
+
+## When To Use
+
+Use this skill whenever a `node-service` project adds, changes, or documents HTTP endpoints.
+
+## Framework And Placement
+
+- Use `hono` only.
+- Keep transport concerns under `src/http/`.
+- Keep very small route wiring in `src/http/http-server.service.ts` when that remains clear.
+- Extract `*.controller.ts` or `*.schema.ts` only when endpoint count or validation complexity justifies them.
+- Keep business logic in feature or app services, not in transport handlers.
+
+## Route Design
+
+- Prefer pure REST resource routes.
+- Use plural resource names in URL paths.
+- Use `kebab-case` path segments.
+- Keep code feature folders singular even when route paths are plural.
+- Reserve `GET /` for service info, health, or root metadata when the template already uses it.
+- Put business routes under `/api/<resource-plural>`.
+
+Examples:
+
+- `GET /`
+- `GET /api/users`
+- `GET /api/users/:userId`
+- `POST /api/users`
+- `PATCH /api/users/:userId`
+- `DELETE /api/users/:userId`
+
+## Method Rules
+
+- `GET` for retrieval
+- `POST` for creation
+- `PUT` only for real full replacement
+- `PATCH` for partial updates
+- `DELETE` for deletion
+
+Defaults:
+
+- prefer `PATCH` over `PUT` unless full replacement semantics are real
+- avoid action verbs in paths when a resource-oriented route works
+- if a non-REST action is unavoidable, use `POST /api/<resource-plural>/:resourceId/<action-kebab-case>`
+
+## Parameters
+
+### Path Params
+
+- use lowerCamelCase names with `Id` suffix for identifiers
+- use semantic names such as `userId` or `invoiceId`
+- do not use generic names such as `id`, `item`, or `value`
+
+### Query Params
+
+Use query params only for read modifiers:
+
+- filtering
+- pagination
+- sorting
+- search
+
+Canonical names:
+
+- `page`
+- `pageSize`
+- `sort`
+- `search`
+- feature-specific names such as `status`, `fromDate`, `toDate`
+
+Rules:
+
+- keep query params flat
+- avoid nested query structures
+- avoid ad hoc operator syntax unless current behavior truly requires it
+
+## Request Bodies
+
+- `GET` and `DELETE` must not accept bodies
+- `POST`, `PUT`, and `PATCH` use JSON bodies
+- bodies should be plain objects by default
+- avoid generic `{ data: ... }` wrappers unless there is a current need for metadata
+
+## Success Responses
+
+- return plain JSON payloads by default
+- do not introduce a generic transport envelope without current need
+- return arrays directly for simple collections
+- return metadata objects only when metadata actually exists
+
+Status defaults:
+
+- `GET`: `200`
+- `POST` create: `201`
+- `PATCH` and `PUT`: `200`
+- `DELETE`: `204` with no body
+- `POST` async accepted work: `202` only when genuinely asynchronous
+
+For `201` responses:
+
+- include a `Location` header when a canonical resource URL exists and doing so is straightforward
+
+## Error Responses
+
+Use this transport error shape:
+
+```json
+{
+  "code": "invalid_request",
+  "message": "Human-readable explanation"
+}
+```
+
+Optional:
+
+- `details` only when validation detail is genuinely useful
+
+Canonical error codes:
+
+- `invalid_request`
+- `not_found`
+- `conflict`
+- `internal_error`
+
+Status mapping:
+
+- invalid path, query, body, or header input: `400`
+- missing resource: `404`
+- state conflict: `409`
+- unexpected failure: `500`
+
+Defaults:
+
+- prefer `400` over `422` unless there is an explicit product reason
+- keep error responses small and stable
+- never leak stack traces or internals
+
+## Validation
+
+- validate path params, query params, and bodies at the HTTP boundary
+- keep validation near transport
+- use `<feature>.schema.ts` only when validation is non-trivial enough to justify it
+- inline trivial validation when it stays compact and obvious
+- validation failures must return the standard `400` error shape
+- validation logic must not drift into domain services
+
+## README And Tests
+
+Whenever HTTP behavior changes:
+
+- update `## HTTP API`
+- document method and path
+- document params
+- document success status
+- document response shape
+- document meaningful failure statuses
+- keep examples aligned with actual routes and payloads
+
+For meaningful endpoint changes, tests should cover:
+
+- success status
+- success payload
+- validation failure when applicable
+- not-found or conflict behavior when applicable
+- `204` no-body behavior when applicable

package/resources/ai/templates/skills/init-workflow/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: init-workflow
+description: Use this skill when implementing the first behavior in a freshly generated scaffold. It defines the required execution order, scaffold-preservation rules, and final reporting for init-based work.
+---
+
+# Init Workflow
+
+## When To Use
+
+Use this skill when the project was generated with `code-standards init` and the task is to implement new behavior inside the fresh scaffold.
+
+## Read First
+
+- `AGENTS.md`
+- `SKILLS.md`
+- `ai/contract.json`
+- `ai/rules.md`
+- `prompts/init-contract.md`
+- `src/index.ts`
+- `src/config.ts`
+
+## Required Execution Order
+
+1. Inspect the generated scaffold before changing code so the public shape and feature layout stay aligned with the template.
+2. Map the requested behavior onto the existing `src/` and `test/` structure before adding files.
+3. Implement the smallest correct change inside the scaffold-native structure.
+4. Update or add tests for the behavior change.
+5. If `README.md` changes, load `skills/readme-authoring/SKILL.md` and rewrite the README after behavior is stable.
+6. Run `npm run standards:check`.
+7. Fix every `error`, review every `warning`, report every `audit` item, and rerun until the default verification passes.
+8. Run `npm run check`.
+9. Fix failures and rerun `npm run check` until it passes.
+
+## Prohibited Actions
+
+- Do not replace scaffold structure with an unrelated architecture.
+- Do not edit managed files unless the user explicitly asked for a standards update.
+- Do not introduce helper layers, wrappers, or extra files unless the current requirement justifies them.
+- Do not leave `README.md` as scaffold text when the task changes real behavior.
+
+## Implementation Focus
+
+- Preserve scaffold naming conventions and feature boundaries.
+- Keep helper logic inside classes as private or static methods in class-oriented source files.
+- Split oversized classes into smaller cohesive units instead of keeping monolithic files.
+- Keep generated and edited content in English, including code comments, README text, and examples.
+
+## Final Response Checklist
+
+- List changed files.
+- Include a short compliance checklist.
+- Provide proof that `npm run check` passed.

package/resources/ai/templates/skills/readme-authoring/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: readme-authoring
+description: Use this skill when creating or updating README.md. It defines the required documentation workflow, evidence to collect from the public API, and quality checks for package-grade README output.
+---
+
+# README Authoring
+
+## When To Use
+
+Use this skill when the task creates, rewrites, or updates `README.md`.
+
+## Read First
+
+- `AGENTS.md`
+- `ai/contract.json`
+- `ai/rules.md`
+- `README.md`
+- `src/index.ts`
+- `src/config.ts`
+
+## Workflow
+
+1. Inspect the real public exports from `src/index.ts`.
+2. Inspect public class methods that are reachable through the package boundary.
+3. Inspect `src/config.ts` and extract each user-facing configuration key and its impact.
+4. Inspect scripts, runtime constraints, and actual usage flow before writing prose.
+5. Rewrite `README.md` so it matches the real behavior rather than the scaffold.
+
+## Writing Rules
+
+- Write the README in English.
+- Write like the package maintainer speaking to another engineer.
+- Lead with fast value, runnable commands, and practical examples.
+- Keep the README focused on real package or runtime behavior.
+- Document every public export from `src/index.ts`.
+- If a public export is a class, document each public method with purpose, return value, and behavior notes.
+- Include runnable examples that import from the real package boundary.
+- Describe configuration in user terms, not as a raw constant dump.
+
+## Avoid
+
+- Do not leave placeholder language, TODOs, or scaffold narration.
+- Do not describe the project as generated or templated outside the `AI Workflow` section.
+- Do not force the reader to inspect source files to understand the public API.
+- Do not claim support, behavior, or setup steps that the code does not implement.
+
+## Validation
+
+- Verify the README still matches the current public API and commands.
+- Verify examples are copy-pasteable and aligned with the actual package surface.
+- Verify the README reflects the final behavior after code changes, not before them.

package/resources/ai/templates/skills/refactor-workflow/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: refactor-workflow
+description: Use this skill when refactoring an existing project or rebuilding legacy code on top of a regenerated scaffold. It defines the required execution order, forbidden actions, and final reporting for scaffold-first refactor work.
+---
+
+# Refactor Workflow
+
+## When To Use
+
+Use this skill when the task is to refactor an existing project, rebuild a legacy implementation on top of a regenerated scaffold, or work from `.code-standards/refactor-source/`.
+
+## Read First
+
+- `AGENTS.md`
+- `ai/contract.json`
+- `ai/rules.md`
+- `.code-standards/refactor-source/public-contract.json`
+- `.code-standards/refactor-source/preservation.json`
+- `.code-standards/refactor-source/analysis-summary.md`
+
+## Required Execution Order
+
+1. Analyze the legacy code and extract only required behavior, preserved contracts, business rules, and edge cases.
+2. Treat the snapshot under `.code-standards/refactor-source/latest/` as reference material only.
+3. Rebuild the solution in the fresh scaffold under `src/` and `test/`.
+4. Compare the planned target structure against the active standards before writing final code.
+5. Run `npm run check`.
+6. Fix failures in `src/` and `test/` and rerun `npm run check` until it passes.
+
+## Prohibited Actions
+
+- Do not copy legacy files into the new scaffold and make only superficial edits.
+- Do not reproduce the legacy folder tree, helper layers, wrappers, plural feature folders, typed errors, or abstraction patterns unless preserved contracts force them.
+- Do not restore `AGENTS.md`, `SKILLS.md`, `skills/*`, `ai/*`, `prompts/*`, `.vscode/*`, `biome.json`, `tsconfig*.json`, `package.json`, or lockfiles from the snapshot.
+- Do not use `git checkout`, `git restore`, or snapshot copies to roll managed files back.
+- Do not preserve unjustified legacy complexity by inertia.
+
+## Implementation Focus
+
+- Prefer the scaffold-native design when legacy structure conflicts with current standards.
+- Fold helper logic into private or static class methods in class-oriented source files.
+- Split oversized classes into smaller cohesive units instead of keeping monolithic files.
+- Keep all generated and edited content in English, including README and code comments.
+
+## Final Response Checklist
+
+- List changed files.
+- Include the preserved contracts checklist.
+- Note intentionally non-preserved legacy items, if any.
+- Provide proof that `npm run check` passed.