create-koppajs 1.2.1 → 1.2.3

package/template/TESTING_STRATEGY.md

@@ -1,93 +0,0 @@
-# Testing Strategy
-
-## Current state
-
-This repository now has a small automated testing stack aligned with the actual starter risk profile:
-
-- `pnpm test:run` for unit and integration tests in Vitest
-- `pnpm test:coverage` for local coverage reporting
-- `pnpm test:e2e` for a Playwright smoke test against `vite preview`
-- `pnpm check` for the fast repository baseline
-- `pnpm validate` for the full local and CI validation path
-- `pnpm release:check` for tagged release candidates
-- `commitlint` through `.husky/commit-msg` for commit message validation
-- `pnpm typecheck`
-- `pnpm build`
-
-## Philosophy
-
-- Test the smallest meaningful unit that gives confidence.
-- Prefer extracting logic into `.ts` modules when it becomes complex enough to warrant focused unit tests.
-- Add test infrastructure only when the repository's behavior justifies it; do not add tools for ceremony alone.
-- Avoid brittle tests that mirror implementation details instead of observable behavior.
-- Reuse the real Vite loading path in automated tests whenever `.kpa` handling is part of the risk surface.
-
-## Test pyramid for this repository
-
-### Unit tests
-
-Use unit tests for isolated logic that can fail independently of the browser runtime. Today that includes the repo-local `.kpa` export normalization helper in `vite.config.mjs`.
-
-Typical triggers:
-
-- value transformations
-- branching business rules
-- reusable helpers
-- local tooling helpers
-
-### Integration or component tests
-
-Use integration tests when multiple local boundaries must be verified together but a full browser run would be disproportionate.
-
-Typical triggers:
-
-- bootstrap registration in `src/main.ts`
-- build-time behavior that depends on the Vite plugin
-- shared state or lifecycle interactions that are not yet broad enough for end-to-end coverage
-
-### End-to-end tests
-
-This repository has a real interactive UI, so it carries one Playwright smoke test already. Keep that layer intentionally small and user-facing.
-
-Typical triggers:
-
-- root UI rendering
-- critical starter interactions such as the counter behavior
-- preview/build regressions that would not be caught by Vitest alone
-
-Escalate E2E coverage beyond smoke scope only when the starter gains broader workflows such as routing, async data flows, persistence, or deployment-sensitive behavior.
-
-## Mocking policy
-
-- Prefer testing pure extracted logic without mocks.
-- Mock only at external boundaries such as HTTP, storage, or browser APIs that are expensive or nondeterministic.
-- Use selective mocks in integration tests only to observe bootstrap boundaries that would otherwise be opaque.
-
-## Coverage expectations
-
-- There is no blanket repository percentage target right now.
-- New non-trivial logic should come with focused tests.
-- When a subsystem introduces branching logic, asynchronous behavior, or state shared across components, test automation stops being optional.
-- Coverage reports are a decision aid, not a target game. Raise thresholds only when the code surface justifies them.
-
-## Quality gates by change size
-
-- Documentation-only change: verify links and document consistency.
-- Small style or copy change: run `pnpm check`.
-- Source or config change: run `pnpm check`.
-- UI, bootstrap, or browser-sensitive change: run `pnpm validate`.
-- Version, changelog, or release workflow change: run `pnpm release:check`.
-- Commit convention change: validate `commitlint.config.mjs` and `.husky/commit-msg` together.
-- New subsystem or new state model: add tests appropriate to the risk level and update this strategy.
-
-## Style linting position
-
-Stylelint is intentionally not part of the current baseline.
-
-- The meaningful styling surface lives inside `.kpa` files.
-- Adding Stylelint only for `src/style.css` would mostly lint the global reset and miss the component-local styles that matter.
-- Revisit this decision only when KoppaJS gains a low-friction way to lint embedded `.kpa` CSS blocks or when the repository starts moving substantial styles into standalone CSS files.
-
-## Maintenance rule
-
-Whenever test tooling, quality gates, or expected confidence levels change, update this file and [docs/quality/quality-gates.md](./docs/quality/quality-gates.md) in the same change.

package/template/_editorconfig

@@ -1,12 +0,0 @@
-root = true
-
-[*]
-charset = utf-8
-end_of_line = lf
-indent_size = 2
-indent_style = space
-insert_final_newline = true
-trim_trailing_whitespace = true
-
-[*.md]
-trim_trailing_whitespace = false

package/template/_github/instructions/ai-workflow.md

@@ -1,33 +0,0 @@
-# AI Workflow Instructions
-
-## Read before editing
-
-For any non-trivial change, read these documents in order:
-
-1. `DECISION_HIERARCHY.md`
-2. `AI_CONSTITUTION.md`
-3. `ARCHITECTURE.md`
-4. the relevant spec in `docs/specs/`
-5. the relevant ADR in `docs/adr/`
-6. `DEVELOPMENT_RULES.md`
-7. `TESTING_STRATEGY.md`
-
-For release-related work also read `CHANGELOG.md` and `RELEASE.md`.
-
-## Required behavior
-
-- Prefer existing repository patterns over new abstractions.
-- Do not silently change public component tags, startup flow, or dependency sourcing.
-- Use `spec -> quality plan -> implementation -> documentation`.
-- Update the meta layer in the same change when architecture, rules, or workflows change.
-- Record durable technical decisions in ADRs.
-- Keep hooks fast and put heavier validation into `pnpm validate` and CI.
-- If versioning, changelog, or release automation changes, update `CHANGELOG.md`, `RELEASE.md`, and the affected workflow in the same change.
-- If you create commits, use Conventional Commits that satisfy `commitlint`.
-
-## Required validation
-
-- Run `pnpm check` for source, config, test, or tooling changes.
-- Run `pnpm validate` when UI behavior, bootstrap wiring, browser-facing assets, or quality tooling changes.
-- Run `pnpm release:check` when versioning, changelog, or release workflow behavior changes.
-- If a local browser check cannot be run, say so explicitly instead of implying it passed.

package/template/_github/workflows/ci.yml

@@ -1,38 +0,0 @@
-name: CI
-
-on:
-  pull_request:
-    branches:
-      - develop
-      - main
-  push:
-    branches:
-      - main
-
-jobs:
-  validate:
-    runs-on: ubuntu-latest
-
-    steps:
-      - name: Check out repository
-        uses: actions/checkout@v4
-
-      - name: Set up pnpm
-        uses: pnpm/action-setup@v4
-        with:
-          version: 10.12.1
-
-      - name: Set up Node.js
-        uses: actions/setup-node@v4
-        with:
-          node-version: 20
-          cache: pnpm
-
-      - name: Install dependencies
-        run: pnpm install --frozen-lockfile
-
-      - name: Install Playwright browser
-        run: pnpm exec playwright install --with-deps chromium
-
-      - name: Run repository validation
-        run: pnpm validate

package/template/_github/workflows/release.yml

@@ -1,58 +0,0 @@
-name: Release
-
-on:
-  push:
-    tags:
-      - "v*.*.*"
-
-jobs:
-  release:
-    name: Create GitHub Release
-    runs-on: ubuntu-latest
-    permissions:
-      contents: write
-
-    steps:
-      - name: Check out repository
-        uses: actions/checkout@v4
-        with:
-          fetch-depth: 0
-
-      - name: Set up pnpm
-        uses: pnpm/action-setup@v4
-        with:
-          version: 10.12.1
-
-      - name: Set up Node.js
-        uses: actions/setup-node@v4
-        with:
-          node-version: 20
-          cache: pnpm
-
-      - name: Install dependencies
-        run: pnpm install --frozen-lockfile
-
-      - name: Install Playwright browser
-        run: pnpm exec playwright install --with-deps chromium
-
-      - name: Validate repository
-        run: pnpm validate
-
-      - name: Verify tag matches package.json version
-        run: |
-          TAG_VERSION="${GITHUB_REF_NAME#v}"
-          PKG_VERSION=$(node -p "require('./package.json').version")
-          echo "Tag version: $TAG_VERSION"
-          echo "Package.json version: $PKG_VERSION"
-          if [ "$TAG_VERSION" != "$PKG_VERSION" ]; then
-            echo "::error::Version mismatch! Tag ($TAG_VERSION) does not match package.json ($PKG_VERSION)"
-            exit 1
-          fi
-          echo "Versions match: $TAG_VERSION"
-
-      - name: Create GitHub Release
-        uses: softprops/action-gh-release@v2
-        with:
-          generate_release_notes: true
-        env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

package/template/_husky/commit-msg

@@ -1,8 +0,0 @@
-commit_msg_file="$1"
-commit_msg_content=$(cat "$commit_msg_file")
-
-if echo "$commit_msg_content" | grep -qE "^(Merge|Revert|fixup!|squash!)"; then
-  exit 0
-fi
-
-pnpm exec commitlint --config commitlint.config.mjs --edit "$commit_msg_file"

package/template/_husky/pre-commit

@@ -1 +0,0 @@
-pnpm exec lint-staged

package/template/_prettierignore

@@ -1,7 +0,0 @@
-.ai
-coverage
-dist
-node_modules
-playwright-report
-pnpm-lock.yaml
-test-results

package/template/commitlint.config.mjs

@@ -1,6 +0,0 @@
-export default {
-  extends: ["@commitlint/config-conventional"],
-  rules: {
-    "header-max-length": [2, "always", 72],
-  },
-};

package/template/docs/adr/0001-keep-the-starter-minimal.md

@@ -1,32 +0,0 @@
-# ADR 0001: Keep the starter minimal
-
-## Context
-
-This repository starts from the maintained minimal starter baseline for KoppaJS
-applications. Its primary audience needs a runnable reference with as little
-incidental complexity as possible.
-
-## Decision
-
-The starter remains intentionally small:
-
-- one HTML shell,
-- one TypeScript bootstrap file,
-- one root KoppaJS view,
-- one stateful child component,
-- published npm packages instead of local monorepo `file:` dependencies,
-- no routing, persistence, shared state, or extra demo subsystems by default.
-
-Any expansion beyond that baseline requires a spec and ADR.
-
-## Consequences
-
-- New users get a fast, low-noise example.
-- The repository stays easy to audit and maintain.
-- More advanced features must be introduced deliberately rather than accumulating ad hoc.
-- Some capabilities are intentionally absent until justified.
-
-## Alternatives considered
-
-- A feature-rich demo app that showcases many KoppaJS patterns at once
-- A monorepo-linked starter that depends on local sibling packages

package/template/docs/adr/0002-adopt-a-living-meta-layer.md

@@ -1,30 +0,0 @@
-# ADR 0002: Adopt a living meta layer
-
-## Context
-
-The repository previously lacked a formal architecture memory, contributor governance, testing philosophy, decision hierarchy, and AI workflow guidance. That made it easy for the implementation and the documentation to drift apart.
-
-## Decision
-
-The project will maintain an in-repository meta layer consisting of:
-
-- root governance documents,
-- architecture support documents under `docs/architecture/`,
-- ADRs under `docs/adr/`,
-- specs under `docs/specs/`,
-- quality and maintenance guidance under `docs/quality/` and `docs/meta/`,
-- AI-specific workflow guidance under `.github/instructions/`.
-
-Whenever architecture, module boundaries, workflow, or quality expectations change, the relevant meta documents must be updated in the same change.
-
-## Consequences
-
-- Contributors and AI agents have a single source of truth inside the repository.
-- Architectural drift becomes easier to detect.
-- Every meaningful change carries a small documentation obligation.
-- The repository gains governance overhead, but the overhead is intentionally light and local.
-
-## Alternatives considered
-
-- Relying on README-only guidance
-- Keeping architectural decisions in issues or chat history instead of versioned documents

package/template/docs/adr/0003-normalize-kpa-plugin-output.md

@@ -1,24 +0,0 @@
-# ADR 0003: Normalize KPA plugin output
-
-## Context
-
-The installed `@koppajs/koppajs-vite-plugin` currently transforms `.kpa` files into raw object literals during Vite loading. Rollup expects valid ES module syntax, so production builds fail unless the transformed output is wrapped in an export.
-
-## Decision
-
-Keep using the upstream KoppaJS Vite plugin, but add a small repo-local post-transform in `vite.config.mjs` that converts raw `.kpa` object literals into `export default ...` modules.
-
-This workaround remains in place until the upstream plugin emits valid module syntax on its own.
-
-## Consequences
-
-- The repository builds successfully without changing application source files.
-- The workaround is isolated to build configuration.
-- Future maintainers must remove or revise the wrapper if the upstream plugin behavior changes.
-- Architecture documentation must reflect that the build stack includes this compatibility layer.
-
-## Alternatives considered
-
-- Patching `node_modules` directly
-- Rewriting application imports around the plugin defect
-- Leaving the repository in a state where `pnpm build` fails

package/template/docs/adr/0004-adopt-an-automated-quality-baseline.md

@@ -1,31 +0,0 @@
-# ADR 0004: Adopt an automated quality baseline
-
-## Context
-
-The repository already had a living meta layer and a real interactive UI, but its practical quality gates were still limited to `pnpm typecheck`, `pnpm build`, and manual smoke testing. That left the repo-local `.kpa` build workaround, bootstrap wiring, and browser-visible starter behavior exposed to easy regression.
-
-## Decision
-
-Adopt a proportional automated quality baseline for the starter:
-
-- ESLint for TypeScript source and tooling files,
-- Prettier and `.editorconfig` for supported text formats,
-- Vitest for unit and integration coverage of local tooling and bootstrap behavior,
-- Playwright for one Chromium smoke path against `vite preview`,
-- Husky and lint-staged for fast staged-file checks,
-- GitHub Actions CI that runs the same validation flow as local contributors.
-
-Do not add Stylelint yet. The meaningful styles live inside `.kpa` blocks, and a CSS-file-only lint setup would give false confidence while adding maintenance overhead.
-
-## Consequences
-
-- The starter gets repeatable local and CI validation without inflating the runtime architecture.
-- Browser-visible regressions are caught automatically instead of relying only on manual smoke tests.
-- Contributors have a clearer script contract: `check` for the fast baseline and `validate` for the full suite.
-- Future maintainers must keep the test, hook, CI, and documentation layers aligned when the quality stack changes.
-- Stylelint remains an explicit future decision instead of an accidental omission.
-
-## Alternatives considered
-
-- Staying on `typecheck + build + manual smoke test`
-- Adding a heavier test and lint stack, including Stylelint, before the repository has enough surface area to justify it

package/template/docs/adr/0005-adopt-a-tag-driven-release-baseline.md

@@ -1,45 +0,0 @@
-# ADR 0005: Adopt a tag-driven release baseline
-
-## Context
-
-The repository had gained a real quality baseline, governance documents, and a
-`develop`/`main` branch model, but it still lacked an explicit release contract.
-That left version bumps, changelog updates, and GitHub tagging behavior too
-implicit for a maintained official starter.
-
-`koppajs-core` already uses a documented tag-driven release path with guarded
-automation. This starter benefits from the same clarity, but its release target
-is different because the repository currently stays `private` and is not
-published to npm.
-
-## Decision
-
-Adopt a manual, tag-driven release baseline for this repository:
-
-- maintain `CHANGELOG.md` for official tagged milestones,
-- document the maintainer procedure in `RELEASE.md`,
-- create a GitHub Actions release workflow that runs on `vX.Y.Z` tags,
-- rerun full repository validation during the release workflow,
-- fail the workflow when the pushed tag does not match `package.json`,
-- create GitHub Releases only while the repository remains `private`.
-
-Release content is prepared on `develop`, moved through `release/*`, merged into
-`main`, tagged on `main`, and merged back into `develop` after a successful
-release.
-
-## Consequences
-
-- The repository now has an explicit versioning and release contract.
-- Maintainers must update `package.json`, `CHANGELOG.md`, and `RELEASE.md` in
-  sync when release practice changes.
-- Tagged releases are guarded against accidental version mismatches.
-- The release workflow improves traceability without forcing npm publishing.
-- If this repository later becomes publishable, a new ADR must extend or
-  replace this baseline rather than silently changing the release target.
-
-## Alternatives considered
-
-- Keeping releases informal and undocumented
-- Adding automated versioning via Changesets or semantic-release
-- Copying the npm publish path from `koppajs-core` even though this repository
-  is currently `private`

package/template/docs/adr/0006-adopt-commit-message-conventions.md

@@ -1,39 +0,0 @@
-# ADR 0006: Adopt commit message conventions
-
-## Context
-
-The repository now has staged-file checks, CI validation, and a documented
-release process, but commit history still had no enforced structure.
-
-That makes release review, changelog preparation, and future maintenance harder
-than necessary, especially for an official starter that should model a clear
-workflow for contributors.
-
-`koppajs-core` already enforces conventional commit messages with `commitlint`.
-The same baseline is appropriate here because it adds little overhead while
-improving traceability.
-
-## Decision
-
-Adopt Conventional Commits enforcement through `commitlint`:
-
-- add `@commitlint/cli` and `@commitlint/config-conventional`,
-- validate commit messages in `.husky/commit-msg`,
-- keep the rule set intentionally small,
-- enforce a maximum header length of 72 characters,
-- allow the existing fast `pre-commit` hook to stay focused on staged files.
-
-## Consequences
-
-- Contributors now need to use structured commit headers such as
-  `feat: add release workflow` or `docs: update quality workflow`.
-- Invalid commit messages are rejected before the commit is created.
-- The repository gains a cleaner history for release review and maintenance.
-- If the project later needs custom commit types or scopes, the change should go
-  through `commitlint.config.mjs` and matching documentation updates.
-
-## Alternatives considered
-
-- Keeping commit messages informal
-- Enforcing commit conventions only socially without a hook
-- Adding heavier release automation before stabilizing the commit baseline

package/template/docs/adr/README.md

@@ -1,37 +0,0 @@
-# Architecture Decision Records
-
-This directory stores durable architectural and workflow decisions.
-
-## When to write an ADR
-
-Write an ADR when a change:
-
-- changes repository structure,
-- introduces or removes a subsystem,
-- changes dependency sourcing or build tooling,
-- changes public starter behavior in a lasting way,
-- adds a new rule that future contributors must follow.
-
-## Format
-
-Use [`TEMPLATE.md`](./TEMPLATE.md). Every ADR must contain:
-
-- Context
-- Decision
-- Consequences
-- Alternatives considered
-
-## Naming
-
-- Prefix files with a four-digit sequence number.
-- Use a short kebab-case slug.
-- Never rewrite history silently; supersede older ADRs with new ones when decisions change.
-
-## Current ADRs
-
-- [`0001-keep-the-starter-minimal.md`](./0001-keep-the-starter-minimal.md)
-- [`0002-adopt-a-living-meta-layer.md`](./0002-adopt-a-living-meta-layer.md)
-- [`0003-normalize-kpa-plugin-output.md`](./0003-normalize-kpa-plugin-output.md)
-- [`0004-adopt-an-automated-quality-baseline.md`](./0004-adopt-an-automated-quality-baseline.md)
-- [`0005-adopt-a-tag-driven-release-baseline.md`](./0005-adopt-a-tag-driven-release-baseline.md)
-- [`0006-adopt-commit-message-conventions.md`](./0006-adopt-commit-message-conventions.md)

package/template/docs/adr/TEMPLATE.md

@@ -1,18 +0,0 @@
-# ADR XXXX: Title
-
-## Context
-
-Describe the situation, constraints, and forces that make a decision necessary.
-
-## Decision
-
-Describe the chosen approach in direct, testable language.
-
-## Consequences
-
-Explain the expected benefits, tradeoffs, and follow-up obligations.
-
-## Alternatives considered
-
-- Alternative 1
-- Alternative 2

package/template/docs/architecture/module-boundaries.md

@@ -1,48 +0,0 @@
-# Module Boundaries
-
-## Repository boundary model
-
-This repository is intentionally shallow. Its boundaries are designed to keep the starter easy to understand.
-
-| Path                            | Responsibility                                                                             | Allowed dependencies                               | Must not depend on                                                |
-| ------------------------------- | ------------------------------------------------------------------------------------------ | -------------------------------------------------- | ----------------------------------------------------------------- |
-| `index.html`                    | Document shell, root element, asset references                                             | Static assets, `src/main.ts`, `src/style.css`      | Feature logic, extra scripts, framework-specific behavior         |
-| `CHANGELOG.md`                  | Tagged release history                                                                     | Release notes, versioned milestones                | Unreleased planning notes or unrelated contributor guidance       |
-| `RELEASE.md`                    | Maintainer release procedure                                                               | `package.json`, `CHANGELOG.md`, GitHub workflows   | Runtime code or undocumented branch conventions                   |
-| `commitlint.config.mjs`         | Commit message rules                                                                       | Conventional commit policy                         | Source-code linting or release branching rules                    |
-| `src/main.ts`                   | Application bootstrap and component registration                                           | `@koppajs/koppajs-core`, local `.kpa` modules      | UI business logic, ad hoc DOM manipulation, network code          |
-| `src/app-view.kpa`              | Root page layout and composition                                                           | Local markup, local CSS, child components          | Global bootstrap concerns, unrelated feature orchestration        |
-| `src/counter-component.kpa`     | Example local state and interaction                                                        | Local markup, local methods, local CSS             | Shared infrastructure, global state, direct root DOM coordination |
-| `src/style.css`                 | Global reset and truly global base rules                                                   | Standard CSS                                       | Component-specific visual rules                                   |
-| `public/`                       | Static assets served as-is                                                                 | Static files only                                  | Source code or generated artifacts                                |
-| `tests/unit/`                   | Isolated tests for helper and tooling logic                                                | Vitest, local modules                              | Full browser expectations or long integration chains              |
-| `tests/integration/`            | Bootstrap and boundary-level integration tests                                             | Vitest, local modules, selective mocks             | Browser-only smoke assertions                                     |
-| `tests/e2e/`                    | Real-browser smoke coverage                                                                | Playwright, preview server                         | Implementation-detail assertions                                  |
-| `vite.config.mjs`               | Build and dev server integration, including the `.kpa` module export compatibility wrapper | Vite and the KoppaJS Vite plugin                   | Application runtime logic                                         |
-| `vitest.config.mjs`             | Vitest orchestration merged with the Vite config                                           | Vitest and Vite config                             | Application runtime logic                                         |
-| `playwright.config.ts`          | Playwright orchestration against preview output                                            | Playwright and preview server script               | Application runtime logic                                         |
-| `.github/workflows/release.yml` | Tag-triggered validation and GitHub Release creation                                       | GitHub Actions, `package.json`, validation scripts | npm publishing while `package.json` is `private`                  |
-| `tsconfig.json`                 | TypeScript compiler behavior for source, tests, and TS config files                        | TypeScript compiler options                        | Application runtime logic                                         |
-
-## Boundary rules
-
-- Registration happens in `src/main.ts`, not inside component modules.
-- `app-view.kpa` may compose child components but should not become a global state hub by accident.
-- Component-local behavior stays inside the component until reuse or complexity makes extraction worthwhile.
-- Shared logic, once introduced, belongs in dedicated `.ts` modules with tests when justified.
-- Vitest owns helper-level and bootstrap-level confidence; Playwright owns browser smoke confidence.
-- Pre-commit checks stay limited to staged-file hygiene. Heavy validation belongs to `pnpm validate` and CI.
-- Commit-message validation lives in `.husky/commit-msg` and `commitlint.config.mjs`, not in ad hoc contributor lore.
-- Release metadata stays aligned across `package.json`, `CHANGELOG.md`, `RELEASE.md`, and `.github/workflows/release.yml`.
-
-## Escalation rules
-
-Before crossing existing boundaries, add a spec and ADR if the change introduces:
-
-- routing,
-- shared state,
-- async workflows,
-- persistence,
-- more than one root entrypoint,
-- npm publishing or deployment automation,
-- new top-level source folders.

package/template/docs/meta/maintenance.md

@@ -1,40 +0,0 @@
-# Meta-Layer Maintenance
-
-The meta layer is a living system. Any change that alters the real system must update the corresponding governance document in the same change.
-
-## Update matrix
-
-| Change                                     | Required updates                                                                               |
-| ------------------------------------------ | ---------------------------------------------------------------------------------------------- |
-| New feature or behavior                    | Add or update a spec in `docs/specs/`; update `README.md` if setup or visible behavior changes |
-| New enduring technical decision            | Add or update an ADR in `docs/adr/`                                                            |
-| New module, folder, or data flow           | Update `ARCHITECTURE.md` and `docs/architecture/module-boundaries.md`                          |
-| New coding pattern or dependency rule      | Update `DEVELOPMENT_RULES.md`                                                                  |
-| New test tooling or quality gate           | Update `TESTING_STRATEGY.md` and `docs/quality/quality-gates.md`                               |
-| New hook, CI step, or contributor workflow | Update `CONTRIBUTING.md` and `.github/instructions/ai-workflow.md`                             |
-| Version, changelog, or release workflow    | Update `CHANGELOG.md`, `RELEASE.md`, `package.json`, and affected GitHub workflow files        |
-
-## Review triggers
-
-Perform a meta-layer review when:
-
-- a pull request changes the repo structure,
-- a new dependency is added,
-- a public component tag changes,
-- a build or test command changes,
-- a hook or CI workflow changes,
-- a subsystem such as routing or data fetching is introduced,
-- a README section no longer matches the actual code.
-
-## Periodic review checklist
-
-- Does [ARCHITECTURE.md](../../ARCHITECTURE.md) still match the runtime flow?
-- Do current specs cover the user-visible behaviors in the repo?
-- Do ADRs still represent active decisions?
-- Do contributor instructions still match the actual toolchain?
-- Did a recent change deserve a new quality gate?
-- Do `CHANGELOG.md`, `RELEASE.md`, and the release workflow still match actual branch and tag practice?
-- Do commit message examples and hook behavior still match `commitlint.config.mjs`?
-- Is any omitted tooling, such as Stylelint, still intentionally omitted for good reason?
-
-If any answer is "no", update the meta layer before considering the repository aligned.

package/template/docs/quality/quality-gates.md

@@ -1,39 +0,0 @@
-# Quality Gates
-
-## Baseline gates
-
-For the current repository scope, the baseline gates are:
-
-- staged files: `lint-staged` via `.husky/pre-commit`
-- commit messages: `commitlint` via `.husky/commit-msg`
-- fast local repository check: `pnpm check`
-- full repository validation: `pnpm validate`
-- release candidate verification: `pnpm release:check`
-- `pnpm typecheck`
-- `pnpm build`
-- `pnpm test:run`
-- `pnpm test:e2e` for UI, bootstrap, or preview-sensitive changes
-- tagged release automation: `.github/workflows/release.yml` reruns validation and checks tag/version alignment
-
-## Gate escalation rules
-
-Raise the quality bar when the repository grows:
-
-- New extracted logic modules: add unit tests.
-- Multi-component behavior: add integration or component tests.
-- Routing, async workflows, persistence, or deployment-sensitive behavior: expand end-to-end coverage beyond the current smoke scope.
-- If component-local `.kpa` styling grows more complex and a credible linting path appears, revisit the current decision to omit Stylelint.
-
-## Review checklist
-
-- Do setup instructions still work from a clean checkout?
-- Does the documented architecture still match the code layout?
-- Do specs still match observable behavior?
-- Are current quality gates enough for the newest change?
-- Do `CHANGELOG.md`, `RELEASE.md`, and the release workflow still agree on the release path?
-- Do commit message rules and contributor examples still match `commitlint.config.mjs`?
-- Are hooks still fast enough to help rather than hinder contributors?
-
-## Ownership rule
-
-Anyone changing code, tooling, or workflow is responsible for updating the quality gates if the risk profile changes.