@stackonward/cli 0.0.1 → 1.0.1

package/dist/resources/templates/base/.claude/docs/architecture.md

@@ -0,0 +1,137 @@
+# Application Architecture Standard
+
+## 1. Purpose and System Boundary
+
+The generated repository owns application workflows, routes, branding, configuration and release. Shared libraries own reusable mechanisms exposed through public exports. Installed source belongs to the application; package internals remain in the package owner and change through a versioned release.
+
+| Layer                 | Responsibility                                      | Excluded responsibility                          |
+| --------------------- | --------------------------------------------------- | ------------------------------------------------ |
+| Presentation/protocol | Typed input, visible state, tool/resource schema    | Credentials, transport retry, storage policy     |
+| State coordination    | Drafts, selection, operation state, invalidation    | Raw protocol parsing and authorization authority |
+| Application service   | Use case ordering, invariants, result semantics     | Rendering or process connection startup          |
+| Adapter               | External HTTP/storage/provider formats and failures | Navigation, feedback UI, pricing decisions       |
+| Composition           | Configuration, dependencies and lifetime            | Business rules copied out of services            |
+| Pure transformation   | Deterministic conversion of explicit values         | Framework imports, environment reads, network    |
+
+## 2. Read and Reuse Gate (CRITICAL)
+
+Before adding a file, read `package.json`, relevant public exports, existing owners and direct callers. Search responsibilities and sibling symbols with `rg`. Declare exact reused paths and symbols; “reuse common utilities” is insufficient.
+
+**FORBIDDEN**: dependency deep imports into `src/`, copying runtime internals, or adding another HTTP client to bypass the existing error contract. A public export must exist in the installed package and have the required input/result semantics.
+
+```text
+Pure value transformation?
+  → co-locate for one caller; share only with proven reuse
+Uses Vue lifecycle/reactivity?
+  → composable or component
+Translates an external protocol?
+  → service adapter
+Encodes application workflow?
+  → feature owner
+Defines process/request lifetime?
+  → entrypoint, plugin or request composition
+```
+
+✅ Correct: callers extract a byte count and pass it to `formatFileSize(byteLength)`.
+
+❌ Wrong: shared `formatUploadPageFileRow(response)` mixes a page DTO, extraction and formatting. Keep DTO extraction in its consumer; share the value transform.
+
+## 3. Module Complexity
+
+| Complexity             | Evidence                             | Required separation                                     |
+| ---------------------- | ------------------------------------ | ------------------------------------------------------- |
+| Pure function          | No I/O, state or framework lifetime  | Function and precise types                              |
+| Adapter-backed service | External boundary and typed use case | Contract, adapter and composition                       |
+| Stateful workflow      | Transitions, recovery or consistency | Domain invariants, service, adapter and recovery policy |
+
+The complete architectural design remains required for a new boundary even when it occupies few files. File count does not turn a mechanical rename into architecture.
+
+Use actual paths in [Stack](stack.md). Nuxt routes belong in `app/pages/`, server handlers in `server/api/`. MCP registrations belong in `src/tools.ts` / `src/resources.ts`; external adapters belong in `src/services/`. Do not create empty layers to match a diagram.
+
+## 4. File Placement and Types
+
+Request/response types stay beside the service/API owner. Component props/emits stay with the component. A type moves to a shared owner only when callers share semantics, not merely field names.
+
+| Type                       | Owner                                         |
+| -------------------------- | --------------------------------------------- |
+| HTTP request/response      | API or server contract                        |
+| MCP tool input/result      | Tool schema and protocol adapter              |
+| Component props/emits      | Component                                     |
+| Global client preference   | State owner                                   |
+| External provider response | Provider adapter                              |
+| Shared pure value          | Public library contract after reuse is proven |
+
+**MUST** distinguish absence, failure, unsupported capability and partial completion. A boolean cannot represent request acceptance, running state and completion simultaneously.
+
+```typescript
+interface OperationResult {
+  operationId: string;
+  state: "accepted" | "running" | "completed" | "failed";
+  requestedCount: number;
+  completedCount: number;
+}
+```
+
+This illustrates type design, not an installed endpoint. Actual API contracts control naming, states and counts.
+
+✅ Correct: parse unknown input before constructing a typed model.
+
+❌ Wrong: `JSON.parse(text) as OperationResult` is considered validation. Type assertions disappear at runtime.
+
+## 5. Extension Points (CRITICAL)
+
+External APIs, provider choices, themes, configurable policy and tenant context start with a contract and configuration. Implement the current adapter after the consumer-facing interface. Do not first couple callers to a concrete provider and later extract its shape.
+
+```typescript
+interface TextTransformer {
+  transform(input: string, signal: AbortSignal): Promise<string>;
+}
+interface TransformOptions {
+  transformer: TextTransformer;
+  signal: AbortSignal;
+}
+```
+
+Adding a provider should add an adapter and composition/configuration entry. If every page or tool must change, provider details leaked. Credentials, model names and provider parameters belong in configuration and adapters.
+
+Do not combine unrelated workflows into an untyped universal config object. Shared mechanisms require compatible inputs, results, errors, lifetime and ownership.
+
+## 6. Dependency Direction
+
+Framework adapters depend on framework-independent contracts. Shared contracts do not import Vue, Nuxt, MCP server instances or application routes. Composition supplies dependencies; services do not discover them through hidden globals.
+
+Nuxt browser graphs cannot import server-only credentials or Node-only modules. SSR identity/state belongs to request/application context. MCP service code cannot write directly to stdout; the protocol transport owns it.
+
+## 7. Data and State Flow
+
+Trace source → validation → service → adapter → result → state → presentation/protocol output. Preserve names, optionality, units, timezone, pagination, identity scope and unknown enum semantics.
+
+Server state has one authoritative query/cache owner. Client preferences and drafts have separate lifetimes. Do not mirror a query result into another global store without a synchronization contract.
+
+Mutations declare affected cache identities and refresh targets. Refresh failure preserves valid data and drafts. See [Security and Lifecycle](security-lifecycle.md).
+
+## 8. Configuration and Branding
+
+Configuration declares supported choices; it is not authorization. Hidden UI controls cannot replace backend checks. Public environment variables contain only public values; invalid configuration must fail before effects.
+
+Brand tokens, logos, locale and navigation belong to application composition. Generic packages do not branch on product names or hardcode customer routes. Registry-installed components remain editable application source.
+
+## 9. Generated Source Ownership
+
+Projects must run outside the source checkout. **FORBIDDEN**: developer absolute paths, dependency escapes, symlinks to external rules and commands requiring unshipped helpers.
+
+Template changes affect new projects. Existing applications receive reviewed source changes; regeneration never overwrites business code or credentials. CLAUDE and AGENTS remain synchronized complete files.
+
+## 10. Architecture and Delivery
+
+Use [Architecture Template](architecture-template.md) for new architecture. Non-applicable sections require concrete ownership reasons. Plans and alignment evidence belong in ordinary `docs/`.
+
+### Pre-commit Checklist
+
+- [ ] Each new symbol has a searched owner and precise responsibility.
+- [ ] Dependencies use actual installed public exports.
+- [ ] Types, parsing, policy and presentation have separate owners.
+- [ ] Shared contracts have real consumers and explicit lifetime.
+- [ ] Generated applications do not depend on a company checkout.
+- [ ] Failure, retry, stale response and disposal follow the full data path.
+- [ ] Direct consumers pass declared stack checks.

package/dist/resources/templates/base/.claude/docs/index.md

@@ -0,0 +1,42 @@
+# Application Standards Index
+
+Read [CLAUDE.md](../../CLAUDE.md) completely, then select the task boundary:
+
+| Task                               | Standard                                        |
+| ---------------------------------- | ----------------------------------------------- |
+| Modules, dependencies and reuse    | [Architecture](architecture.md)                 |
+| Input, secrets, state and disposal | [Security and Lifecycle](security-lifecycle.md) |
+| Checks and delivery                | [Verification](verification.md)                 |
+| Framework directories and commands | [Selected Stack](stack.md)                      |
+
+Use [Architecture Design Template](architecture-template.md) for new architecture or contract design.
+
+This directory contains current engineering rules. Product designs and implementation evidence belong in ordinary `docs/`; unverified research is not a binding requirement.
+
+## Required Reading Sequence
+
+1. Read root `CLAUDE.md` or its identical full `AGENTS.md` body for the five execution phases and shared forbidden patterns.
+2. Read `stack.md` for the actual generated framework, environment consumers, commands and source owners.
+3. Read `architecture.md` before changing ownership, public types, dependencies or shared abstractions.
+4. Read `security-lifecycle.md` before changing external inputs, identity, credentials, requests, retries, cancellation or disposal.
+5. Read `verification.md` before selecting checks or declaring completion.
+6. Use `architecture-template.md` for the applicable Level A/B/C design depth.
+
+## Full Standard Ownership
+
+| Standard               | Complete topic coverage                                                                                                           |
+| ---------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
+| Root body              | Understand, Design, Plan, Implement, Verify; shared SH rules; delivery; Git; comments; pre-commit                                 |
+| Architecture           | Purpose, layers, reuse, placement, types, extension points, dependency direction, state flow, config, generated-source ownership  |
+| Security and lifecycle | Trust, secrets, authorization, result/error semantics, diagnostics, disposal, stale results, retries, drafts, URLs/files, privacy |
+| Verification           | Command authority, static gates, behavior, browser/protocol, packed consumers, migrations, review, Git and evidence               |
+| Nuxt selected stack    | Modules/env, aliases, SSR, API/query/store, components/theme, full interaction rules, filters, locale and browser acceptance      |
+| MCP selected stack     | Entrypoint, tool/resource schemas, type boundaries, adapters, permissions, stdio, retry, errors, transport and package acceptance |
+
+Only the selected `stack.md` is installed. Base standards never overwrite it with a second framework's rules. Framework-specific source files take precedence over generic examples when resolving actual symbol names, while root security and delivery requirements remain binding.
+
+## Documentation Maintenance (CRITICAL)
+
+**MUST** update the owning rule when a real contract changes; do not append a correction beside stale instructions. Keep useful examples, forbidden patterns and checklist coverage. Do not shorten a complete standard into an index-only entry.
+
+CLAUDE and AGENTS are standalone full files and must remain equal. Relative links must resolve inside the generated project; external source-checkout paths and external symlinks are forbidden. Record source comparison and implementation evidence in ordinary project documentation, not these binding rules.

package/dist/resources/templates/base/.claude/docs/security-lifecycle.md

@@ -0,0 +1,129 @@
+# Security and Lifecycle Standard
+
+## 1. Trust Boundaries (CRITICAL)
+
+This standard applies to browser/server calls, MCP tools/resources, environment configuration and external adapters. **MUST** validate unknown values once at the owning boundary, then pass typed values internally. Do not add repeated null checks for values guaranteed by a framework or validated contract.
+
+| Input              | Validation owner                          | Required checks                                          |
+| ------------------ | ----------------------------------------- | -------------------------------------------------------- |
+| Browser form/query | Client for feedback; server for authority | Type, size, range, allowlist and business rules          |
+| MCP tool arguments | Registered schema and use case            | Type, bounds, required scope and operation permission    |
+| External response  | Provider/API adapter                      | Shape, required fields, status and safe error conversion |
+| Environment        | Configuration consumer                    | Required values, finite numbers, supported values        |
+| URL/path           | Outbound adapter or redirect owner        | Protocol, host/root, normalized path and scope           |
+
+A generic parameter on JSON parsing is not runtime validation. The MCP `safeJsonParse<T>` utility parses syntax only; callers still validate semantics. Nuxt query parameters must be narrowed before use.
+
+✅ Correct: accept unknown tool input through the declared Zod schema, then authorize the concrete resource before effects.
+
+❌ Wrong: accept an arbitrary `user_id` or `product_code` and use it as proof of authority.
+
+## 2. Secrets and Configuration
+
+Private tokens and credentials belong in process/server configuration. **FORBIDDEN**: credentials in source, public Nuxt runtime configuration, app configuration, tool descriptions, resource contents, logs or generated examples.
+
+`NUXT_PUBLIC_*` values are browser-visible. Client IDs may be public; client secrets are not. MCP `.env.example` is a schema/example file and does not install dotenv or make the runtime consume variables automatically.
+
+Declare a variable only with its real configuration consumer. Do not use a default production secret or convert missing credentials into a simulated successful result. Configuration documentation must state whether a value is read at build time or runtime.
+
+## 3. Authorization and Identity Scope
+
+Client controls are presentation, never authorization. Every effectful server/tool operation must enforce the authenticated subject's resource scope at the authoritative service boundary. Do not forward a caller-selected identity header without checking its contract and audience.
+
+| Boundary                | Guarantee                                                     |
+| ----------------------- | ------------------------------------------------------------- |
+| Public route/tool       | Explicit public capability and rate/size bounds               |
+| Authenticated operation | Subject from verified session/token, not payload identity     |
+| Resource read/write     | Scope checked for the selected resource                       |
+| Provider request        | Only configured credentials sent to an allowed destination    |
+| Logout/account switch   | Old identity cache and pending writes cannot affect new state |
+
+For a consumer of an upstream identity platform, use the actual platform API contract. The template does not install OAuth clients, IAM policy engines, account services or backend authorization endpoints.
+
+## 4. Output and Error Contracts
+
+Use stable machine codes and safe messages. Preserve validation, authentication, authorization, rate-limit, unavailable and internal-error distinctions. Presentation may localize safe codes; adapters do not navigate or display UI.
+
+HTTP clients preserve response status and the agreed error envelope. MCP tools distinguish protocol failures from tool execution results with `isError`; failed execution cannot return an ordinary success-shaped result.
+
+✅ Correct: report “permission denied” with a safe code and correlation identifier; keep raw provider diagnostics in a controlled diagnostic boundary.
+
+❌ Wrong: return an empty array after an upstream timeout so the user believes the dataset is empty.
+
+A `204` HTTP response has no body. Do not parse it as JSON. A successful transport exchange does not prove an asynchronous remote operation completed.
+
+## 5. Safe Diagnostics
+
+Log operation IDs, safe error codes, duration and correlation identifiers. Never log passwords, tokens, signed URLs, complete request bodies or personal content by default. Error serialization must not expose credential-bearing request options.
+
+MCP stdout is protocol-owned. Operational diagnostics use stderr and remain redacted. Nuxt browser output cannot reveal server-only stack traces or environment state.
+
+## 6. Resource Ownership (CRITICAL)
+
+Every request, subscription, timer, stream and connection has a creation owner, lifetime and disposal point. State coordination owns active operations; presentation does not create hidden long-lived background work.
+
+| Event                      | Required behavior                                                |
+| -------------------------- | ---------------------------------------------------------------- |
+| Component/request creation | Bind resources to that scope                                     |
+| Route/query change         | Invalidate old results before applying new scope                 |
+| Account change/logout      | Clear identity-scoped state and reject stale responses           |
+| Component disposal         | Abort local work and detach subscriptions                        |
+| MCP transport close        | Stop owned listeners/resources through their real close contract |
+| Process shutdown           | Close resources in dependency order and surface failure          |
+
+Local cancellation only proves that this client stopped waiting unless the remote API acknowledges cancellation. Never display “cancelled” for a remote job solely because an HTTP request was aborted.
+
+## 7. Concurrency and Stale Responses
+
+An operation result may update state only if its identity/query scope still matches the owner. Use the framework query lifecycle where present rather than parallel hand-written loading flags and watchers.
+
+For manually coordinated work, bind an operation sequence or abort signal to the owner. Reject stale results before state changes; merely cancelling the previous fetch is insufficient when a provider ignores abort.
+
+✅ Correct: a query key includes the authenticated identity and resource filter; switching scope invalidates the previous result.
+
+❌ Wrong: a module-global `currentUser` or promise result writes to a new SSR request's state.
+
+## 8. Retries and Idempotency
+
+Retry only failures the contract declares retryable. Bound attempts and total time; honor cancellation and server retry hints. Never retry a mutation automatically without an idempotency contract or proof that the operation was not accepted.
+
+An idempotency key identifies an operation, not a user, display label or third-party resource ID. The authoritative backend owns uniqueness and replay guarantees. A client-side disabled button only prevents one local duplicate action.
+
+| Outcome                | Recovery                                                       |
+| ---------------------- | -------------------------------------------------------------- |
+| Validation failure     | Correct input; do not retry unchanged                          |
+| Authorization failure  | Reauthenticate or resolve permission; no blind loop            |
+| Transient read failure | Bounded retry with visible stale-data state                    |
+| Mutation timeout       | Query operation status or replay by declared idempotency key   |
+| Partial completion     | Preserve completed resources; retry only eligible failed items |
+
+## 9. Drafts and Partial Results
+
+Draft state survives recoverable save failure. Do not close an editor, clear input or replace valid data until the authoritative write succeeds. After success, refresh all directly affected views through the owner cache contract.
+
+Partial output must include meaningful status and completed/failed counts from the service. Do not manufacture progress from elapsed time or imply all resources completed when only a request was accepted.
+
+## 10. Content, URLs and Files
+
+Render untrusted text through framework escaping. Raw HTML requires the specific sanitized-content boundary; a type assertion is not sanitization. Do not add uninstalled sanitizer imports merely to satisfy an example.
+
+For outbound URLs, enforce allowed protocols and destinations at the adapter. For local paths, resolve against the allowed root and reject traversal. Upload size/type checks need authoritative server validation; browser accept filters are user guidance only.
+
+## 11. Audit and Privacy
+
+For effectful operations, preserve actor, action, resource, result and safe correlation metadata through the actual backend/tool contract. A frontend success toast is not an audit record. Do not duplicate authoritative audit records in client stores.
+
+Retention, consent, deletion and export operate on identified data owners. Browser storage and telemetry must respect the application's actual consent contract. Configuration toggles cannot retroactively make already-sent telemetry consented.
+
+## 12. Security and Lifecycle Checklist
+
+- [ ] Unknown input is parsed before side effects.
+- [ ] Public configuration and protocol output contain no private credentials.
+- [ ] Scope is authorized by the owning service, not caller-supplied IDs.
+- [ ] Errors preserve semantic failure and expose safe diagnostics only.
+- [ ] Request, timer, connection and subscription lifetimes are explicit.
+- [ ] Identity/query changes reject stale results and preserve request isolation.
+- [ ] Mutation retries have a real idempotency or acceptance-status contract.
+- [ ] Drafts and partial results survive recoverable failure.
+- [ ] Shutdown/disposal and remote cancellation are distinguished.
+- [ ] Runtime evidence is separate from unit fixtures and compilation.

package/dist/resources/templates/base/.claude/docs/verification.md

@@ -0,0 +1,121 @@
+# Verification and Delivery Standard
+
+## 1. Scope and Command Authority
+
+**MUST** read the generated `package.json`, configuration and [Stack](stack.md) before selecting commands. Run only installed commands; unavailable scripts are not successful checks. Nuxt preparation/build, MCP compilation, browser interaction, protocol acceptance and external service acceptance are separate results.
+
+| Change            | Minimum evidence                                                |
+| ----------------- | --------------------------------------------------------------- |
+| Pure local logic  | Targeted behavior and relevant error paths                      |
+| Public contract   | Producer and direct consumer agree on complete payload          |
+| Async owner       | Cancellation, stale response, retry and disposal                |
+| UI                | Actual route, controls, state transitions and recovery          |
+| MCP tool/resource | Schema, protocol result, error result and compiled transport    |
+| Dependency/export | Resolution, lockfile, consumer compile and packed file coverage |
+| Documentation     | Real files, commands, links, examples and current behavior      |
+
+## 2. Industry Gate Semantics
+
+| Decision          | Pattern                              | Application                                                                                        |
+| ----------------- | ------------------------------------ | -------------------------------------------------------------------------------------------------- |
+| Merge quality     | Required CI status checks            | Inspect actual repository protection and workflow jobs; do not infer protection from documentation |
+| Local feedback    | Installed Git hooks                  | Run existing setup and hooks; do not bypass failures                                               |
+| Existing findings | Non-regression baseline              | Record existing failures separately; reject introduced in-scope regressions                        |
+| Architecture      | Dependency and contract verification | Check actual imports/exports and direct consumers                                                  |
+| Persistence       | Query-backed schema/index evidence   | Apply only when this repository owns persistent schema                                             |
+
+The template does not ship OneX governance analyzers or its branch-protection settings. Their architectural purpose remains required; their command names cannot be copied into this application's instructions.
+
+## 3. Understand and Design Verification
+
+Before edits, identify the owning module, public surface, direct consumers and relevant rules. Architecture designs must include concrete target types, state flow, error behavior, configuration, dependency assembly and verification.
+
+Use [Architecture Template](architecture-template.md). Reconcile every accepted requirement to an implemented owner and observable result. A heading or an external link does not prove requirement coverage.
+
+✅ Correct: API field addition is traced through parsing, service result, query state and displayed value.
+
+❌ Wrong: a backend type compiles while the consumer still reads the old field.
+
+## 4. Static and Build Gates
+
+Run the appropriate declared typecheck and build. Check changed imports, exports, config keys, routes and registrations with `rg`. Run `git diff --check` and inspect the final diff.
+
+Nuxt declares format, lint, typecheck, test, build and the composed `pnpm check` gate. MCP declares format, lint, typecheck, test and build through its stack-owned scripts. Run the selected stack's actual commands; do not report MCP protocol results from Nuxt checks or Nuxt rendering results from MCP tests.
+
+A build validates graph and artifact generation. It does not prove authorization, signed credentials, successful uploads, external jobs or publication.
+
+## 5. Behavioral Verification
+
+Tests must assert observable guarantees at the changed boundary, not mirror implementation details. Use fake providers only inside tests. Verify explicit errors and avoid success-shaped defaults.
+
+| Case                   | Question                                                  |
+| ---------------------- | --------------------------------------------------------- |
+| Valid input            | Does the intended result reach the consumer?              |
+| Invalid input          | Is it rejected before effects with meaningful details?    |
+| Missing identity/scope | Does the authoritative boundary reject access?            |
+| Provider failure       | Does error identity survive translation?                  |
+| Duplicate mutation     | Is replay/idempotency behavior correct?                   |
+| Timeout                | Is ambiguous acceptance handled without double execution? |
+| Partial result         | Are completed items retained and failures recoverable?    |
+| Cancellation/disposal  | Can stale work still modify current state?                |
+
+Do not add tests for a reversible wording-only change solely to increase counts. Test schema parsing, contract changes and asynchronous invariants because their behavior can fail.
+
+## 6. Nuxt Browser Acceptance
+
+For touched UI, inspect the actual generated route. Include parent and child components, overlays, teleported content and responsive behavior. A parent source scan is not a runtime component inventory.
+
+Required applicable states: initial loading, valid content, empty collection, absent optional field, recoverable error, expired/forbidden access, long text, partial output and refreshing existing data. Verify keyboard focus, dismissal, disabled actions and accessible names.
+
+For writes, prove submit → network result → visible success/error → refresh. Keep drafts on failure. Browser console and relevant network results are part of the evidence; a screenshot alone does not prove action behavior.
+
+## 7. MCP Protocol Acceptance
+
+Build first, then use the compiled stdio entry. Verify initialization, declared capabilities, tool listing/call, resource listing/read and connection close with a protocol client. stdout must contain protocol frames only.
+
+Schema validation, result content type and `isError` behavior must match the SDK contract. Unknown tool/resource and invalid arguments need explicit protocol behavior. A `pnpm start:stdio` process launch alone is not a successful request exchange.
+
+Tests of services with fake dependencies do not prove actual provider permission or availability. Report the external-service boundary separately.
+
+## 8. Distribution and Generated Projects
+
+For template changes, generate an application outside the source workspace using the packed CLI. Verify substituted variables, complete CLAUDE/AGENTS bodies, `.claude/docs`, relative links, package resolution and executable commands.
+
+Do not rely on workspace symlinks to satisfy dependencies. Inspect packed files and the consumer artifact. The generated project must not reference developer absolute paths or template placeholders.
+
+Template updates do not authorize overwriting an existing application's source. Nonempty targets and consumer-owned edits must remain protected.
+
+## 9. Data Migration Evidence
+
+When an application owns schema changes, validate migration sequence, fresh creation, supported existing-data state and reversibility where applicable. A clean empty database alone does not validate imported production data.
+
+Every new index must name the real query path and its filter/sort/uniqueness rationale. Match equality prefixes and partial predicates to runtime queries; avoid indexes justified only by field existence. Runtime exact-match dedupe needs a matching authoritative uniqueness constraint.
+
+When persistence belongs to an upstream service, verify that API contract instead of adding local copies of platform tables.
+
+## 10. Review and Failure Handling
+
+Deterministic checks come first. LOCAL work uses no independent reviewer. FOCUSED/ARCHITECTURAL work selects only the relevant rule, architecture or integration dimensions whose judgment can falsify the touched scope, normally zero to three reviewers.
+
+Fix every in-scope blocking finding. Limit ordinary review-fix cycles to two unless new blocking evidence appears. Unrelated findings are reported without expanding the change. Failed commands remain failures until rerun successfully or identified as an exact external blocker.
+
+## 11. Git and Release
+
+Inspect working tree and staged files; preserve unrelated edits. Run the existing hooks when configured. Use normal commits only: no amend, history rewrite, rebase-based repair or force push.
+
+Resolve push rejection by fetch, inspect and normal merge. Never bypass hook or CI failures. Publication and deployment require the relevant authorization; tests and builds do not implicitly publish.
+
+## 12. Delivery Evidence
+
+Report concrete changed behavior, exact validation scope, command outcomes and remaining external limitations. Do not claim product authentication, payments or generation are accepted from foundation tests alone.
+
+### Pre-commit Checklist
+
+- [ ] Source owners, consumer contracts and complete rules were read.
+- [ ] Accepted requirements map to actual implementation and proof.
+- [ ] Declared static/build checks pass for the touched stack.
+- [ ] Applicable success, failure, cancellation and recovery behavior is verified.
+- [ ] Browser/protocol evidence covers the changed interactions.
+- [ ] Packed/template consumers are independent of the source checkout.
+- [ ] No secrets, dead references, deferred code or process residue remain.
+- [ ] Normal Git history and existing hook requirements are respected.