create-koppajs 1.2.2 → 1.2.3

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: 22
-          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-rely-on-upstream-kpa-es-module-output.md

@@ -1,32 +0,0 @@
-# ADR 0003: Rely on upstream KPA ES module output
-
-## Context
-
-The starter depends on `@koppajs/koppajs-vite-plugin` to transform `.kpa`
-files for both development and production builds.
-
-Earlier starter revisions carried a repo-local compatibility wrapper in
-`vite.config.mjs` because the plugin emitted raw object literals instead of ES
-modules.
-
-The current upstream plugin now emits `export default ...` modules directly, so
-keeping the local wrapper would only duplicate behavior and create drift
-between the starter and the official plugin contract.
-
-## Decision
-
-Use the upstream KoppaJS Vite plugin output directly and keep `vite.config.mjs`
-limited to plugin wiring.
-
-## Consequences
-
-- The starter stays aligned with the official Vite plugin behavior instead of
-  carrying a stale local workaround.
-- Build configuration stays smaller and easier to reason about.
-- Future maintainers must update the starter and the plugin together if the
-  `.kpa` module contract changes again.
-
-## Alternatives considered
-
-- Keeping a repo-local post-transform in `vite.config.mjs`
-- Forking the plugin behavior inside the starter

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 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-rely-on-upstream-kpa-es-module-output.md`](./0003-rely-on-upstream-kpa-es-module-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,47 +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/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 through the upstream KoppaJS Vite plugin | 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.

package/template/docs/specs/README.md

@@ -1,36 +0,0 @@
-# Specifications
-
-Specs define expected behavior before or alongside implementation. They are the highest-precedence project documents.
-
-## When a spec is required
-
-Create or update a spec when a change:
-
-- introduces or changes user-visible behavior,
-- adds a subsystem,
-- changes public setup or bootstrap behavior,
-- changes a feature in a way that needs explicit acceptance criteria.
-
-## Required structure
-
-Use [`TEMPLATE.md`](./TEMPLATE.md). Each spec should define:
-
-- purpose
-- behavior
-- inputs
-- outputs
-- constraints
-- edge cases
-- acceptance criteria
-
-## Lifecycle
-
-- Draft or update the relevant spec before implementing a non-trivial change.
-- Keep the spec narrow and testable.
-- If implementation diverges from the spec, reconcile them immediately.
-
-## Current specs
-
-- [`app-bootstrap.md`](./app-bootstrap.md)
-- [`counter-component.md`](./counter-component.md)
-- [`quality-workflow.md`](./quality-workflow.md)

package/template/docs/specs/TEMPLATE.md

@@ -1,34 +0,0 @@
-# Spec: Title
-
-## Status
-
-Draft | Approved | Superseded
-
-## Purpose
-
-Describe why this behavior exists.
-
-## Behavior
-
-Describe the observable behavior.
-
-## Inputs
-
-Describe user, system, or configuration inputs.
-
-## Outputs
-
-Describe rendered output, state changes, or side effects.
-
-## Constraints
-
-List constraints that implementation must respect.
-
-## Edge cases
-
-List the important boundary conditions.
-
-## Acceptance criteria
-
-- Criterion 1
-- Criterion 2

package/template/docs/specs/app-bootstrap.md

@@ -1,46 +0,0 @@
-# Spec: App bootstrap
-
-## Status
-
-Approved
-
-## Purpose
-
-Provide a predictable, minimal startup path for a standalone KoppaJS application.
-
-## Behavior
-
-- The application starts from `index.html`.
-- The HTML shell loads one global stylesheet and one module entrypoint.
-- The document declares exactly one root custom element: `<app-view>`.
-- `src/main.ts` registers `app-view` and `counter-component` with KoppaJS Core.
-- `src/main.ts` invokes `Core()` once to bootstrap the application.
-
-## Inputs
-
-- Browser loading `index.html`
-- Static asset and source file paths resolved by Vite
-
-## Outputs
-
-- A rendered `<app-view>` application shell
-- A registered `<counter-component>` available to the root view
-
-## Constraints
-
-- There must be a single bootstrap entrypoint.
-- The root tag in `index.html` must stay aligned with the component registered in `src/main.ts`.
-- No hidden self-registration inside component modules.
-- Bootstrap must rely on the public KoppaJS root API via `Core()` rather than non-public setup helpers.
-- No extra runtime dependencies are required beyond the declared npm packages.
-
-## Edge cases
-
-- If a component tag changes, both `index.html` and `src/main.ts` must be updated together.
-- If more bootstrap behavior is added, it must not introduce a second source of truth for initialization.
-
-## Acceptance criteria
-
-- Opening the app through Vite renders the root view without manual DOM scripting.
-- `src/main.ts` remains the only location that calls `Core()`.
-- The root view can render the counter component immediately after bootstrap.

package/template/docs/specs/counter-component.md

@@ -1,48 +0,0 @@
-# Spec: Counter component
-
-## Status
-
-Approved
-
-## Purpose
-
-Demonstrate local interactive state in a minimal KoppaJS component.
-
-## Behavior
-
-- The component renders a "Counter" label, a numeric count, and increment/decrement buttons.
-- The initial count is `0`.
-- Clicking the increment button increases the count by `1`.
-- Clicking the decrement button decreases the count by `1`.
-- The displayed count updates immediately after each click.
-- The increment and decrement buttons expose stable accessible names.
-- The rendered count is announced politely to assistive technology when it changes.
-
-## Inputs
-
-- User clicks on the increment button
-- User clicks on the decrement button
-
-## Outputs
-
-- Updated numeric text rendered in the component
-- No external side effects
-
-## Constraints
-
-- State is local to the component.
-- The component performs no persistence, networking, or cross-component coordination.
-- The component remains embeddable inside the root app shell.
-
-## Edge cases
-
-- Negative values are allowed.
-- Repeated clicks continue to update the count linearly within normal JavaScript number behavior.
-
-## Acceptance criteria
-
-- The counter is visible inside the app shell when the starter loads.
-- The first rendered value is `0`.
-- A single click on `+` changes the value from `0` to `1`.
-- A single click on `-` changes the value from `0` to `-1`.
-- Assistive technology can distinguish the increment and decrement actions without relying on symbol glyphs alone.