@manhd_d/ai-harness 0.11.0 → 0.13.0

package/CHANGELOG.md

@@ -1,5 +1,29 @@
 # Changelog
 
+## Unreleased — Kiro and clearer tool setup
+
+- Add Kiro to all README languages and a documented IDE/CLI/Web setup guide with optional native skill pointers.
+- Separate AI tool installation from project Harness setup; use Core-first npx commands, explicit loading checks and client-specific instruction bridges for all six tools.
+- Preserve native settings; document unreleased Claude flags and Kiro ownership. Add guide/parity/package assertions. No installer, manifest/schema or runtime behavior change; no live-host compatibility claim.
+
+
+## Unreleased — Agent-first delivery and brownfield
+- Route scoped work through agent contracts/preferred skills and approved SA decisions; retire Java outbox/migration and Astro cloud/microfrontend recipes.
+- Add Analysis/Discovery canonical Product profiles, PM/template aliases, shared document contract and host-native/Claude model seeds without overwriting existing settings.
+- Add opt-in Claude import/native wrappers, bounded Maven modules, checkpoint/history/resume and local manual 18-run comparison.
+- Simplify progressive context and README; add Chinese/Spanish translations, migration and behavior/evidence tests. No model calls, merge or npm publish.
+
+
+## Unreleased
+
+### Added
+- Continuous development workflow: fresh baselines, proportional cross-role impact, selective living documentation and source-policy proposals, feedback triage and session handoff.
+- Seven Core behavioral scenarios plus a cross-capability scenario, installation/update preservation coverage and package checks.
+
+### Changed
+- Existing Core/Product/Architecture/Delivery skills and OpenSpec templates retain stable IDs and distinguish implementation, merge and release evidence.
+- Product 1.5.0, Architecture/Delivery 1.1.0; no new runtime, CLI commands or config schemas. Distribution version and release automation remain unchanged.
+
 ## Unreleased — Adaptive verification and TechSpec
 - Add read-only adaptive discovery and digest/pointer-based requirement evidence validation; preserve advisory verify behavior.
 - Add Core verification and Product 1.4.0 selective TechSpec maintenance using existing artifact routes/policies.
@@ -115,6 +139,20 @@
 - Check release metadata consistency and establish single-release-PR version discipline; retain v0.6.0 until a dedicated release PR.
 
 
+## [0.13.0](https://github.com/manh0303/ai-harness/compare/v0.12.0...v0.13.0) (2026-10-13)
+
+
+### Features
+
+* make harness agent-first and portable across projects ([5286c66](https://github.com/manh0303/ai-harness/commit/5286c66cb0895c412da4ff9f0a1e05c4b54f3881))
+
+## [0.12.0](https://github.com/manh0303/ai-harness/compare/v0.11.0...v0.12.0) (2026-10-13)
+
+
+### Features
+
+* continuous development and living documentation ([e87f007](https://github.com/manh0303/ai-harness/commit/e87f007c31a4a0d99f98b47f75c00ff632d92023))
+
 ## [0.11.0](https://github.com/manh0303/ai-harness/compare/v0.10.0...v0.11.0) (2026-10-13)
 
 

package/README.md

@@ -1,55 +1,43 @@
 # AI Harness
 
-**English** · [Tiếng Việt](docs/i18n/README.vi.md)
+**English** · [Tiếng Việt](docs/i18n/README.vi.md) · [简体中文](docs/i18n/README.zh-CN.md) · [Español](docs/i18n/README.es.md)
 
-**Reusable project instructions for AI-assisted development: Requirements → Code → Test → Review.**
+Reusable agent workflows for software development: **Requirements → Design → Code → Test → Review.**
 
-Install Harness in your project, then give tasks to your preferred AI coding tool.
+Give an idea, existing docs or a change request to your AI coding tool. Harness helps it inspect the project, clarify open decisions, implement accepted scope and maintain relevant specs/docs. Use only the roles and skills the task needs.
 
-## What can it help with?
-
-| Workflow | Outputs |
-| --- | --- |
-| **BA / PO — Business analysis & product** | Turn ideas or existing docs into BRD, PRD, SRS, user stories and acceptance criteria. |
-| **SA — Solution architecture** | Architecture, non-functional requirements, technical decisions and change-impact analysis. |
-| **PM — Delivery planning** | Delivery phases, dependencies, risks and scope changes. |
-| **Dev / QA — Implementation & testing** | Feature implementation, debugging, tests and code review following project conventions. |
-| **UI/UX & DevOps** | UI design, CI/CD, deployment and operations guidance when needed. |
-
-Stack adapters: Spring Boot, React/Next.js, React Native/Expo, Python AI/RAG, Astro and Kubernetes.
-Select only what you need; small tasks do not require a full set of docs or a spec. [Choose your stack & modules](docs/getting-started.md).
-
-## Where can you use it?
-
-| AI coding tool | Usage | Guide |
-| --- | --- | --- |
-| **Codex** | CLI or IDE extension | [Install & setup](docs/tool-setup/codex.md) |
-| **Claude Code** | Run `claude` in the project terminal | [Install & setup](docs/tool-setup/claude-code.md) |
-| **Cursor** | Open the project and use Agent | [Install & setup](docs/tool-setup/cursor.md) |
-| **GitHub Copilot** | IDE Agent or Copilot CLI | [Install & setup](docs/tool-setup/copilot.md) |
-| **Gemini CLI** | Run `gemini` in the project terminal | [Install & setup](docs/tool-setup/gemini-cli.md) |
-
-Harness installs instructions; your AI tool executes the work. Follow each guide for tool-specific instruction loading.
+Works with any project through Core workflows. Optional stack support: Spring Boot, React/Next.js, React Native, Python, Astro and Kubernetes. Stack selection does not choose infrastructure or architecture.
 
 ## Quick start
 
-Requires **Node.js 22+** and an AI coding tool above. Run in your project directory:
+Install/sign in to an AI tool below. Requires Node.js 22+. Run in your **project root** terminal:
 
 ```bash
-npx --yes @manhd_d/ai-harness init --detect
+npx --yes @manhd_d/ai-harness init
 ```
 
-Open your AI tool in the same project and send:
+`npx` does not install a global `aih` command. Check the installation with
+`npx --yes @manhd_d/ai-harness check`; then open the same project in your AI tool.
+
+Then ask your AI tool:
+
+> Read AGENTS.md. Inspect this project and its approved decisions. Implement [task], run appropriate checks and maintain the affected docs.
+
+Use `init --detect` for supported stack detection. Existing project instructions and custom skills are preserved; `check` checks Harness integrity. Your host executes application tests and controls tools, delegation and permissions.
 
-> Read AGENTS.md, inspect the project and record relevant context in .harness/local.md.
-> Implement: [describe your task]. Run appropriate tests and report the results.
+## Where it runs
 
-Give tasks normally; you do not need to invoke each agent or skill, or open a chat for each role.
-If `--detect` cannot identify the stack, [select modules explicitly](docs/getting-started.md).
-`aih check` checks Harness files; application correctness requires project tests and review.
+| AI tool | Environment | Install the tool | Harness setup |
+| --- | --- | --- | --- |
+| **Codex** | CLI, IDE or connected cloud workspace | [Install](https://developers.openai.com/codex/quickstart/) | [Guide](docs/tool-setup/codex.md) |
+| **Claude Code** | Project terminal | [Install](https://code.claude.com/docs/en/setup) | [Guide](docs/tool-setup/claude-code.md) |
+| **Cursor** | IDE Agent | [Install](https://cursor.com/docs) | [Guide](docs/tool-setup/cursor.md) |
+| **GitHub Copilot** | IDE Agent or CLI | [Install](https://docs.github.com/en/copilot) | [Guide](docs/tool-setup/copilot.md) |
+| **Gemini CLI** | Project terminal | [Install](https://geminicli.com/docs/) | [Guide](docs/tool-setup/gemini-cli.md) |
+| **Kiro** | IDE, CLI or connected Web workspace | [Install](https://kiro.dev/docs/getting-started/installation/) | [Guide](docs/tool-setup/kiro.md) |
 
-[Getting started](docs/getting-started.md) · [Docs & examples](docs/README.md) · [Input/output & integrations](docs/artifact-contract.md) · [Model/agent configuration](docs/agent-configuration.md)
+Local/cloud execution and external inputs depend on the host's actual access. MCP/connector/API connections can supply docs, designs, tickets and evidence under project source policies.
 
-[Contributing](CONTRIBUTING.md) · [Harness maintenance](docs/harness-maintenance.md) · [MIT](LICENSE).
+[Getting started](docs/getting-started.md) · [Docs & examples](docs/README.md) · [Input/output](docs/artifact-contract.md) · [Agent configuration](docs/agent-configuration.md) · [Continuous development](docs/continuous-development.md)
 
-[Adaptive verification & TechSpec](docs/adaptive-verification.md): project-aware plans, requirement-linked evidence and selective docs.
+[Contributing](CONTRIBUTING.md) · [Harness maintenance](docs/harness-maintenance.md) · [MIT](LICENSE)

package/adapters/ai-python/adapter.yaml

@@ -42,5 +42,5 @@
   ],
   "verification": "checks/verification.yaml",
   "evaluation": "evals/cases.json",
-  "module_version": "1.0.0"
+  "module_version": "1.1.0"
 }

package/adapters/ai-python/rules.md

@@ -1,5 +1,8 @@
 # AI / Python adapter
 
+## Design authority
+Actual host/user permissions apply. For design within its scope: approved SA/ADR decisions > existing project conventions > adapter defaults. Proposed technologies need alternatives, trade-offs and an owner decision before implementation; accepted choices are reused without asking again. Selecting this adapter does not select any infrastructure or pattern.
+
 Inspect the actual Python version, package manager, provider SDK, orchestration and data boundaries.
 This adapter works for model-backed APIs, agents and RAG; those architectures are optional choices.
 

package/adapters/ai-python/skills/harness-ai-python-rag-access/SKILL.md

@@ -6,6 +6,7 @@ description: Build retrieval with enforceable document access and grounded answe
 # rag-access
 
 ## Input
+Approved SA/ADR decisions for the affected scope, existing project conventions and actual stack versions. This skill implements accepted design; it does not select infrastructure, dependencies or architecture.
 Document identities/revisions, tenant ACL policy, retrieval interface and evaluation dataset.
 
 ## Procedure

package/adapters/ai-python/skills/harness-ai-python-tool-safety/SKILL.md

@@ -6,6 +6,7 @@ description: Build bounded model tool calls with independent authorization.
 # tool-safety
 
 ## Input
+Approved SA/ADR decisions for the affected scope, existing project conventions and actual stack versions. This skill implements accepted design; it does not select infrastructure, dependencies or architecture.
 Tool contracts, runtime permission policy, budget/timeouts and side-effect boundaries.
 
 ## Procedure

package/adapters/astro/adapter.yaml

@@ -1,7 +1,7 @@
 {
   "schema_version": 2,
   "id": "astro",
-  "description": "Static-first Astro and TypeScript micro-tool websites with selective framework islands, SEO, Cloudflare Workers deployment and optional micro frontend evolution.",
+  "description": "Astro framework support following approved project architecture and hosting decisions.",
   "detection": [
     {
       "file": "package.json",
@@ -21,11 +21,9 @@
     "harness-astro-project-architecture",
     "harness-astro-islands",
     "harness-astro-seo",
-    "harness-astro-performance",
-    "harness-astro-cloudflare",
-    "harness-astro-microfrontend"
+    "harness-astro-performance"
   ],
   "verification": "checks/verification.yaml",
   "evaluation": "evals/cases.json",
-  "module_version": "1.0.0"
+  "module_version": "1.1.0"
 }

package/adapters/astro/checks/verification.yaml

@@ -33,7 +33,7 @@
     },
     {
       "id": "tool-browser",
-      "title": "Review micro-tool accessibility, privacy and browser workflows",
+      "title": "Review applicable Astro page accessibility and browser behavior",
       "command": [],
       "when_file": null,
       "evidence": [
@@ -44,14 +44,14 @@
       "execution": "manual"
     },
     {
-      "id": "cloudflare-release",
-      "title": "Confirm Cloudflare runtime compatibility and explicit deployment approval",
+      "id": "approved-hosting",
+      "title": "Review approved runtime compatibility and deployment authorization",
       "command": [],
       "when_file": null,
       "evidence": [
-        "Correct Astro output mode/adapter and selected Cloudflare target",
-        "Preview asset/routing/caching verification",
-        "Named owner approved production change; no deploy executed by Harness"
+        "Actual approved host/runtime and output mode",
+        "Preview/build compatibility evidence",
+        "Actual owner permission; installation does not deploy"
       ],
       "execution": "manual"
     }

package/adapters/astro/evals/cases.json

@@ -32,12 +32,12 @@
       "critical": true
     },
     {
-      "id": "cloudflare-static-vs-ssr",
-      "prompt": "Deploy a browser-only JSON formatter to Cloudflare with the lowest reasonable cost and complexity.",
+      "id": "no-host-selected",
+      "prompt": "An Astro project has approved UX requirements but no hosting decision. Implement the requested feature.",
       "criteria": [
-        "Starts from static deployment with no Worker/API or database unless required",
-        "Checks actual build output and host runtime compatibility instead of inventing current quotas",
-        "Requires explicit deploy approval and does not claim to have executed cloud operations"
+        "Does not silently select Cloudflare or another provider",
+        "Uses approved design and asks SA/owner only for consequential deployment gaps",
+        "Does not add microfrontend architecture or invent deployment evidence"
       ],
       "critical": true
     }

package/adapters/astro/rules/architecture.md

@@ -1,9 +1,3 @@
-# Architecture — Astro micro-tools
+# Astro framework boundaries
 
-- Default to static-first Astro pages, layouts and small TypeScript utilities. Prefer browser-local APIs for QR generation, formatting, small image operations and similar no-server tasks.
-- One website may host many tool routes: `src/pages/tools/<tool>.astro`, shared layouts, reusable UI and isolated `src/lib/<tool>/` functions. Avoid centralized mutable state and coupling between unrelated tools.
-- Choose `output: 'static'` when routes need no runtime rendering. Confirm target Astro version and adapter compatibility before introducing on-demand SSR, actions, API routes or server middleware.
-- A tool with secret credentials, restricted APIs, large server jobs or authoritative writes needs a separately justified secure server boundary. Keep secrets out of browser bundles and build output.
-- Reuse existing UI/design and semantic HTML. React islands are optional and load only where genuine interaction needs them; static Astro pages should not inherit a full React runtime.
-- Discuss a monorepo only when there are shared packages, coordinated releases or truly independent teams; a tools folder is enough initially.
-- Keep architecture decisions reversible: one tool owns its UI, data transformations and tests; dependencies cross via explicit interfaces.
+Read actual output mode, integrations, routes and layouts. Follow approved SA design; use Astro version documentation to implement its server/browser boundaries and assets. Neither a /tools route convention nor static-only rendering is required. Hydration and framework integration follow actual UI requirements and accepted bundle trade-offs.

package/adapters/astro/rules/deployment.md

@@ -1,9 +1,3 @@
-# Deployment — static vs Cloudflare Workers
+# Astro deployment compatibility
 
-- Inspect the repository's package manager, lockfile, actual build command, output mode, server adapter and target runtime; do not assume a pre-installed Wrangler or Cloudflare account.
-- Static Astro output usually needs only static hosting/CDN, with no origin backend or database. Browser-local tools do not require Workers.
-- For new **Cloudflare** projects, validate the current official recommendation for Workers and adapter setup instead of assuming Pages-specific integration. Existing Pages deployments may remain valid under their compatibility constraints.
-- On-demand rendering/APIs require a runtime/adapter matching the Astro version; confirm compatibility for Cloudflare Workers and chosen configuration using upstream docs.
-- Configure deploy variables/secrets in the host, not client-visible `PUBLIC_*` values. Confirm environment separation, domain routing, cache behavior and fallback/404 handling.
-- Use preview/staging, real production build output and asset smoke checks before any approved deploy. Gate writes and releases via Product/DevOps authorization; never execute `wrangler deploy` or change DNS without approval.
-- For future MFE route splitting, define ownership of path, domain, cookies/auth, navigation, asset URLs, SEO/canonicals, monitoring and rollback before introducing separate deployments.
+Inspect approved hosting/runtime, package manager, configured build and output mode. Check Astro/server adapter compatibility against that target's actual versions. Use configured preview checks and report missing access. No cloud provider, account, domain change or deployment is selected or executed by installing this adapter.

package/adapters/astro/rules.md

@@ -1,17 +1,8 @@
-# Astro adapter — static-first micro-tools
+# Astro support
 
-Astro should be the light, SEO-friendly shell for independent small utilities. Use TypeScript and browser-native capabilities by default. Prefer **zero backend and zero database** until a requirement justifies them.
+## Design authority
+Actual host/user permissions apply. Approved SA/ADR decisions > existing project conventions > adapter defaults. New technology needs alternatives, trade-offs and owner acceptance; reuse accepted decisions.
 
-## Read before implementation
-- Inspect installed Astro version, package manager, routes, integrations, output mode and actual scripts. Never assume a Vite or Astro minor-version API.
-- Read `rules/architecture.md`, `rules/security.md`, `rules/performance.md`, `rules/deployment.md` and only the relevant namespaced skills.
-- Distinguish static HTML, hydrated UI islands, server routes and **separately deployable** micro frontends. Astro Islands are not Module Federation.
-- Avoid adopting React, Tailwind, SSR, a Cloudflare adapter, API/server, storage, auth or a monorepo just because they are available.
+Inspect the installed Astro version, rendering mode, integrations, router/layout conventions and configured scripts. Support static, hybrid or server rendering according to approved requirements. Do not select a host, UI framework, backend, database, monorepo or microfrontend model.
 
-## Safe workflow
-Product approval/requirements → route/tool boundary and privacy model → static-first code with minimal client JS → real build/UX tests → reviewed release. Do not run deployments, fetch unauthorized third-party content or assert permissions without evidence.
-
-## Verification
-`aih verify` returns checklists without running commands; inspect package scripts and execute checks through an authorized host. Keep Core TDD/debugging/review; optional Product/UIUX/DevOps provide cross-cutting workflows.
-
-Official references: https://docs.astro.build/en/guides/framework-components/ and https://docs.astro.build/en/guides/deploy/cloudflare/.
+Read only relevant [architecture](rules/architecture.md), [security](rules/security.md), [performance](rules/performance.md) and [deployment](rules/deployment.md) support. Existing TypeScript/JavaScript and framework choices take precedence. Use actual build/browser evidence, not inferred results.

package/adapters/astro/skills/harness-astro-islands/SKILL.md

@@ -6,17 +6,18 @@ description: Apply selective Astro Islands and optional React integration withou
 # Astro islands and React integration
 
 ## Input
+Approved SA/ADR decisions for the affected scope, existing project conventions and actual stack versions. This skill implements accepted design; it does not select infrastructure, dependencies or architecture.
 - Astro page/component tree and identified interaction needs.
 - Installed @astrojs/react or other framework integrations, versions, hydration constraints and UX requirements.
 
 ## Procedure
 1. Separate static content from interactive islands and document which input/output needs browser state.
-2. Prefer native forms and small browser scripts if sufficient; add a framework integration only when real complexity justifies its bundle cost.
+2. Prefer native forms and small browser scripts if sufficient; reuse approved integrations; propose missing consequential integration choices to SA/owner before adding dependencies.
 3. For approved React components, confirm `@astrojs/react` setup and use `client:load` for immediately interactive UI, `client:idle` or `client:visible` when deferred hydration fits the UX.
 4. Keep private logic, API keys and session enforcement on the server; do not confuse Astro server frontmatter with secret-safe client props.
 5. Guard network requests against stale responses and unmount races; support keyboard interaction, loading/error/empty states and clear focus.
 6. Inspect JS and hydration in actual browser/test builds; compare against a native Astro implementation.
-7. Explain that islands in one Astro build are NOT separate deployable micro frontends; reference the microfrontend skill when independent releases are required.
+7. Explain that islands in one Astro build are NOT separate deployable micro frontends; return open independent-release choices to SA for alternatives and actual owner decision.
 
 ## Output
 - Small interactive island(s), hydration rationale, reviewed imports and client JS evidence.

package/adapters/astro/skills/harness-astro-performance/SKILL.md

@@ -6,6 +6,7 @@ description: Reduce Astro page JavaScript, images and hydration cost while prese
 # Astro performance
 
 ## Input
+Approved SA/ADR decisions for the affected scope, existing project conventions and actual stack versions. This skill implements accepted design; it does not select infrastructure, dependencies or architecture.
 - Actual performance issue or quality goal, existing Astro build, package manager and route/island structure.
 - Measurements from browser/profiler or build reports where available.
 

package/adapters/astro/skills/harness-astro-project-architecture/SKILL.md

@@ -1,28 +1,18 @@
 ---
 name: harness-astro-project-architecture
-description: Design static-first Astro micro-tool websites with TypeScript, isolated tool modules and minimal infrastructure.
+description: Implement approved project boundaries with the actual Astro rendering mode, routes and integrations.
 ---
 
-# Astro project architecture
+# Astro project support
 
 ## Input
-- Approved problem, tool pages, audience, expected traffic, user data and quality requirements.
-- Existing Astro version, package scripts, router/layouts, deploy mode, optional integrations and lockfile.
-
+Approved SA/ADR decisions, scoped requirements, existing conventions and actual Astro versions/output mode.
 ## Procedure
-1. Inspect existing `astro.config.*`, `package.json`, routing and tool dependencies; avoid inventing a new project if one exists.
-2. Prefer static HTML/TypeScript/browser APIs, one `src/pages/tools/<tool>.astro` route per tool and a small dedicated library module for each tool's logic.
-3. Separate tool UI, pure transformations, validation, side effects and test fixtures. Share layouts/design tokens only when multiple tools need them.
-4. Only introduce server endpoints for justified access control, secrets, trusted writes or compute. Record backend/data costs and alternatives; default to no database.
-5. Define route ownership, error/empty/success states and storage/privacy expectations; only add React islands for genuinely stateful interaction.
-6. Design stable boundaries so a heavy tool may later move to independent hosting without making the initial app a complex micro frontend platform.
-7. Follow the Core spec → test → review flow; verify actual build/route behavior with existing project scripts.
-
+1. Inspect existing Astro config, routes/layouts, assets and configured commands.
+2. Implement only accepted rendering, component and integration boundaries. Reuse comparable code.
+3. Clarify consequential unresolved choices with SA/owner; do not choose hosting or add backend/DB/frameworks from a recipe.
+4. Verify applicable route/build/browser behavior through authorized host tools and record evidence.
 ## Output
-- An architecture decision and route/module map; minimal Astro/TypeScript changes tied to approved requirements.
-- Actual test/build evidence, plus deferred infrastructure decisions.
-
+Scoped implementation, test evidence and handoff to QA/SA for actual gaps.
 ## Constraints
-- Avoid premature microservices, shared state stores, module federation, Redis, Kubernetes or mandatory authentication.
-- Don't silently add packages, cloud resources, telemetry or external data access.
-- `aih` distributes guidance; it does not scaffold or execute an Astro project.
+No mandatory micro-tools layout, cloud provider or deployment model; preserve approved architecture and user content.

package/adapters/astro/skills/harness-astro-seo/SKILL.md

@@ -6,6 +6,7 @@ description: Build discoverable and accessible Astro utility pages with accurate
 # Astro SEO for useful utilities
 
 ## Input
+Approved SA/ADR decisions for the affected scope, existing project conventions and actual stack versions. This skill implements accepted design; it does not select infrastructure, dependencies or architecture.
 - Target search intent and approved page copy, routes, domain/deployment base URL and localization.
 - Existing metadata, robots, sitemap integration, performance metrics and brand constraints.
 

package/adapters/java-spring/adapter.yaml

@@ -33,11 +33,9 @@
     "rules/conventions.md"
   ],
   "skills": [
-    "harness-java-spring-spring-api",
-    "harness-java-spring-kafka-outbox",
-    "harness-java-spring-database-migration"
+    "harness-java-spring-spring-api"
   ],
   "verification": "checks/verification.yaml",
   "evaluation": "evals/cases.json",
-  "module_version": "1.1.0"
+  "module_version": "1.2.0"
 }

package/adapters/java-spring/rules/database.md

@@ -1,3 +1,3 @@
-# Database
+# Persistence
 
-Make transaction boundaries explicit. Use BigDecimal with a domain-defined rounding policy for money and explicit business timezones. Design idempotent retried writes and test concurrent updates. Use the deployed SQL dialect for integration tests. Evolve schemas with expand/contract migrations and deployment ordering. Persist domain change plus outbox event in the same transaction; consumers deduplicate.
+Use the project's actual database dialect, migration tool and approved data contracts. Align Spring transaction boundaries with accepted business semantics; test rollback and concurrency where relevant. Ask only unresolved deployment/compatibility decisions before schema changes. Do not add a broker, event relay, cache, migration framework or transaction pattern from this adapter. SA assesses those options when requirements demand them.

package/adapters/java-spring/rules/performance.md

@@ -1,3 +1,3 @@
-# Performance
+# Spring performance
 
-Inspect query counts and execution plans before optimizing. Bound result sizes, pagination, retry counts and timeouts. Address N+1 queries and suitable indexes. Define cache scope, TTL and invalidation before adding Redis. Use managed bounded executors for asynchronous work. Measure latency and resource usage under representative load; do not infer performance gains from code shape.
+Inspect actual query counts, execution plans, connection pools and request profiles before changing behavior. Use existing pagination/concurrency settings and measure under relevant load. Propose new caching or asynchronous infrastructure to SA only when evidence shows a requirement; use the chosen project's documentation for implementation details.

package/adapters/java-spring/rules.md

@@ -1,5 +1,8 @@
 # Java / Spring Boot adapter
 
+## Design authority
+Actual host/user permissions apply. For design within its scope: approved SA/ADR decisions > existing project conventions > adapter defaults. Proposed technologies need alternatives, trade-offs and an owner decision before implementation; accepted choices are reused without asking again. Selecting this adapter does not select any infrastructure or pattern.
+
 Read the actual build files, JDK toolchain, Spring BOM, database dialect and local conventions first.
 Prefer the project's Maven/Gradle wrapper. No Spring, Java or dependency upgrades are implied by installation.
 
@@ -12,7 +15,7 @@ For Modulith projects verify module dependencies; use public module APIs, not an
 Use explicit transaction boundaries. Test concurrent updates and idempotency for retried writes.
 Use BigDecimal with an explicit rounding policy for money. Use Instant/offset-aware times and an explicit
 business timezone. Avoid accidental N+1 queries and unbounded queries; define pagination and indexes.
-If using an outbox, persist the business change and outbox event in one transaction; consumers deduplicate.
+For messaging or consistency changes, use approved SA contracts and existing project mechanisms. Do not select a messaging pattern from this adapter.
 Retries require bounds and retryable error classification. Async work needs a managed executor.
 
 ## Contracts and security

package/adapters/java-spring/skills/harness-java-spring-spring-api/SKILL.md

@@ -6,6 +6,7 @@ description: Implement a Spring API with resource-scoped authorization and stabl
 # spring-api
 
 ## Input
+Approved SA/ADR decisions for the affected scope, existing project conventions and actual stack versions. This skill implements accepted design; it does not select infrastructure, dependencies or architecture.
 Approved endpoint contract, actual Spring version, existing controller/service patterns and access policy.
 
 ## Procedure

package/adapters/kubernetes/adapter.yaml

@@ -54,5 +54,5 @@
   ],
   "verification": "checks/verification.yaml",
   "evaluation": "evals/cases.json",
-  "module_version": "1.0.1"
+  "module_version": "1.1.0"
 }

package/adapters/kubernetes/rules.md

@@ -1,5 +1,8 @@
 # Kubernetes adapter
 
+## Design authority
+Actual host/user permissions apply. For design within its scope: approved SA/ADR decisions > existing project conventions > adapter defaults. Proposed technologies need alternatives, trade-offs and an owner decision before implementation; accepted choices are reused without asking again. Selecting this adapter does not select any infrastructure or pattern.
+
 Use this adapter for manifest, Helm and rollout decisions. Combine with the `devops` capability for broader release/incident workflows. It never grants cluster permissions.
 
 Read `rules/architecture.md`, `rules/security.md` and `rules/reliability.md` before applying the

package/adapters/kubernetes/skills/harness-kubernetes-helm-release/SKILL.md

@@ -6,6 +6,7 @@ description: Review Helm charts, versioned dependencies and environment-aware re
 # harness-kubernetes-helm-release
 
 ## Input
+Approved SA/ADR decisions for the affected scope, existing project conventions and actual stack versions. This skill implements accepted design; it does not select infrastructure, dependencies or architecture.
 - Chart, values overlays, image provenance, namespace and target Kubernetes version.
 
 ## Procedure

package/adapters/kubernetes/skills/harness-kubernetes-rollout-safety/SKILL.md

@@ -6,6 +6,7 @@ description: Plan Kubernetes rollout checks, observable abort gates and recovery
 # harness-kubernetes-rollout-safety
 
 ## Input
+Approved SA/ADR decisions for the affected scope, existing project conventions and actual stack versions. This skill implements accepted design; it does not select infrastructure, dependencies or architecture.
 - Deployment manifest, replica count, traffic patterns, health telemetry, application migration plan.
 
 ## Procedure

package/adapters/kubernetes/skills/harness-kubernetes-workload-review/SKILL.md

@@ -6,6 +6,7 @@ description: Review Kubernetes workloads for resources, readiness, security and
 # harness-kubernetes-workload-review
 
 ## Input
+Approved SA/ADR decisions for the affected scope, existing project conventions and actual stack versions. This skill implements accepted design; it does not select infrastructure, dependencies or architecture.
 - Rendered manifests, workload requirements, Kubernetes version and approved environment policy.
 
 ## Procedure

package/adapters/react-native/adapter.yaml

@@ -27,5 +27,5 @@
   ],
   "verification": "checks/verification.yaml",
   "evaluation": "evals/cases.json",
-  "module_version": "1.2.0"
+  "module_version": "1.3.0"
 }

package/adapters/react-native/rules.md

@@ -1,5 +1,8 @@
 # React Native adapter
 
+## Design authority
+Actual host/user permissions apply. For design within its scope: approved SA/ADR decisions > existing project conventions > adapter defaults. Proposed technologies need alternatives, trade-offs and an owner decision before implementation; accepted choices are reused without asking again. Selecting this adapter does not select any infrastructure or pattern.
+
 Inspect whether the project uses Expo or bare React Native, its navigation, native modules and supported OS
 versions. Follow the existing package manager and native build toolchain; do not silently migrate architectures.
 

package/adapters/react-native/skills/harness-react-native-behavior-testing/SKILL.md

@@ -6,6 +6,7 @@ description: Verify React Native and Expo screens using existing JavaScript, nav
 # Mobile behavior testing
 
 ## Input
+Approved SA/ADR decisions for the affected scope, existing project conventions and actual stack versions. This skill implements accepted design; it does not select infrastructure, dependencies or architecture.
 Changed screen/AC, actual test scripts/runner and navigation setup, affected platforms, native/device
 access, and existing API/storage/permission fixtures.
 

package/adapters/react-native/skills/harness-react-native-device-permissions/SKILL.md

@@ -6,6 +6,7 @@ description: Implement device permissions and deep-link flows safely.
 # device-permissions
 
 ## Input
+Approved SA/ADR decisions for the affected scope, existing project conventions and actual stack versions. This skill implements accepted design; it does not select infrastructure, dependencies or architecture.
 Required device capability, platform support matrix and navigation/access policy.
 
 ## Procedure

package/adapters/react-native/skills/harness-react-native-offline-sync/SKILL.md

@@ -6,6 +6,7 @@ description: Implement offline state transitions and safe synchronization in Rea
 # offline-sync
 
 ## Input
+Approved SA/ADR decisions for the affected scope, existing project conventions and actual stack versions. This skill implements accepted design; it does not select infrastructure, dependencies or architecture.
 Offline UX, backend idempotency contract, local data policy and conflict rules.
 
 ## Procedure

package/adapters/react-native/skills/harness-react-native-screen-delivery/SKILL.md

@@ -6,6 +6,7 @@ description: Implement React Native or Expo screens with existing navigation, fo
 # Mobile screen delivery
 
 ## Input
+Approved SA/ADR decisions for the affected scope, existing project conventions and actual stack versions. This skill implements accepted design; it does not select infrastructure, dependencies or architecture.
 Task/AC and screen/flow notes, API contract, actual Expo/bare setup and router/version, supported
 platforms, and existing navigation/theme/client/storage/test paths.
 

package/adapters/react-nextjs/adapter.yaml

@@ -27,5 +27,5 @@
   ],
   "verification": "checks/verification.yaml",
   "evaluation": "evals/cases.json",
-  "module_version": "1.2.0"
+  "module_version": "1.3.0"
 }

package/adapters/react-nextjs/rules.md

@@ -1,5 +1,8 @@
 # React / Next.js adapter
 
+## Design authority
+Actual host/user permissions apply. For design within its scope: approved SA/ADR decisions > existing project conventions > adapter defaults. Proposed technologies need alternatives, trade-offs and an owner decision before implementation; accepted choices are reused without asking again. Selecting this adapter does not select any infrastructure or pattern.
+
 Inspect package.json, lockfile, router choice, TypeScript settings and project scripts. Do not assume npm,
 App Router or a Next.js version; plain React projects use only the applicable rules.
 

package/adapters/react-nextjs/skills/harness-react-nextjs-accessible-ui/SKILL.md

@@ -6,6 +6,7 @@ description: Build accessible React UI states using the existing design system.
 # accessible-ui
 
 ## Input
+Approved SA/ADR decisions for the affected scope, existing project conventions and actual stack versions. This skill implements accepted design; it does not select infrastructure, dependencies or architecture.
 Approved screen/flow, design system components and API contract.
 
 ## Procedure

package/adapters/react-nextjs/skills/harness-react-nextjs-behavior-testing/SKILL.md

@@ -6,6 +6,7 @@ description: Verify React and Next.js features with user-facing component, integ
 # Web behavior testing
 
 ## Input
+Approved SA/ADR decisions for the affected scope, existing project conventions and actual stack versions. This skill implements accepted design; it does not select infrastructure, dependencies or architecture.
 Changed feature/AC, confirmed package scripts and test configuration, framework/router/version,
 available browser/build access, and the existing fixtures/providers/API test boundary.
 

package/adapters/react-nextjs/skills/harness-react-nextjs-feature-delivery/SKILL.md

@@ -6,6 +6,7 @@ description: Implement React or Next.js feature slices with existing routes, com
 # Web feature delivery
 
 ## Input
+Approved SA/ADR decisions for the affected scope, existing project conventions and actual stack versions. This skill implements accepted design; it does not select infrastructure, dependencies or architecture.
 Task/acceptance IDs, approved screen or compact UX notes, API contract, actual framework/router/version,
 and existing convention/component/client/state paths. Read only relevant source and skills.