@manhd_d/ai-harness 0.7.0 → 0.8.0

package/CHANGELOG.md

@@ -1,5 +1,30 @@
 # Changelog
 
+## Unreleased — Agent preferences and release regression
+- Add provider-agnostic project-owned agents.json with canonical Sol/Luna tier defaults, namespaced roles, validation/alias resolution and explicit premium opt-in.
+- Add non-interactive init presets and read-only setup host plans; preserve custom config and legacy snapshots. No native config writes, agent runtime or usage claims.
+- Add orchestrator/documentation contracts, proportional routing/token guidance and official-source host recipes.
+- Repair release update tests to use source-relative versions rather than hardcoded 0.7.0; retain downgrade protection.
+
+## Unreleased — Product and solution delivery
+- Complete Product BA/PO with usable MVP/outcomes, synthetic examples, quality checklists and handoff contracts; module 1.2.0.
+- Add optional Architecture and Delivery 1.0.0 modules: source-linked context, NFR, architecture/pattern trade-offs, ADR, living map/review, value slices, risks and scope changes.
+- Connect proportional Core framing and OpenSpec design/tasks; add checks and unscored behavioral scenarios.
+- Add new-doc --capability while retaining Product default paths and enforcing locked declared templates.
+- Add official-source setup recipes for Codex, Claude Code, Cursor, Copilot and Gemini CLI, plus provenance/research and migration guidance. No native host or live-model compliance result is claimed.
+
+## Unreleased — Harness maintenance contract
+- Add one maintainer guide linking component ownership, impact matrix, change checklist and existing architecture/release contracts.
+- Add a maintainer-only impact template and GitHub PR checklist; require per-area done/pending/not-applicable evidence through repository AGENTS and contributing guidance.
+- Add CI tests for maintainer entry points, impact-area consistency and installed Core/adapter rule discovery.
+- Fix Kubernetes rule discovery exposed by the new test; module contract 1.0.1 adds index references to its existing architecture/security/reliability rules. No schema or executable runtime changes.
+
+## Unreleased — Project coding conventions
+- Add Core new/maintain/mixed scope, convention precedence, search-before-create and architecture-fit review.
+- Add Java/Spring, React/Next.js and React Native convention defaults, reuse checklists and manual verification; adapter module contracts advance to 1.1.0.
+- Connect generated AGENTS, setup, implementation/bugfix/review roles and design templates; preserve existing project-owned context.
+- Add eight behavioral scenarios and regression coverage for installed assets and update ownership. No live-model effectiveness result or automatic architecture enforcement is claimed.
+
 ## Unreleased — Project setup, clarification and readiness
 - Add optional shared environment configuration and ignored machine path overrides, with redacted doctor diagnostics.
 - Add read-only setup suggestions, host-led A/B/C clarification and next-step guidance.
@@ -59,6 +84,20 @@
 - Check release metadata consistency and establish single-release-PR version discipline; retain v0.6.0 until a dedicated release PR.
 
 
+## [0.8.0](https://github.com/manh0303/ai-harness/compare/v0.7.0...v0.8.0) (2026-10-12)
+
+
+### Features
+
+* add project-aware coding conventions and reuse review ([ee1fad0](https://github.com/manh0303/ai-harness/commit/ee1fad0cc447ec6d41f07739a250b103d8df8845))
+* add project-owned agent configuration and host routing plans ([8786294](https://github.com/manh0303/ai-harness/commit/8786294a0542b92998169b1cdb6199c88e8f4a20))
+* add solution architecture and delivery workflows with host setup ([b75c00b](https://github.com/manh0303/ai-harness/commit/b75c00b43ab706768ad92ae2a280879eb7745489))
+
+
+### Bug Fixes
+
+* connect Harness maintenance impact and rule discovery checks ([bc79f56](https://github.com/manh0303/ai-harness/commit/bc79f56f6052917a0e28d895597547485d6bfb83))
+
 ## [0.7.0](https://github.com/manh0303/ai-harness/compare/v0.6.2...v0.7.0) (2026-10-12)
 
 

package/CONTRIBUTING.md

@@ -1,5 +1,9 @@
 # Contributing
 
+Start with [Harness maintenance](docs/harness-maintenance.md): map the impact of each change and
+trace affected declarations through installation, AI discovery, workflow, verification and docs.
+Use its impact template and the PR checklist; explain not-applicable areas and keep pending work visible.
+
 Create a feature branch and an OpenSpec change for meaningful behavior or policy changes.
 Keep executable behavior tests alongside CLI changes. Document adapter expectations without pinning
 consumer application versions arbitrarily. Do not run a model evaluation with secrets or production data.

package/README.md

@@ -27,16 +27,26 @@ Thêm `--capabilities product` khi cần tài liệu BA; `aih new-doc prd-lite`
 Cấu hình Maven/JDK riêng từng máy: [Project configuration](docs/project-configuration.md).
 Trước code/review tính năng có spec: [Change readiness](docs/change-readiness.md).
 
+
+Coding convention cho dự án mới/maintain: [Project conventions](docs/project-conventions.md).
+AI đọc cấu trúc, tìm common phù hợp trước khi tạo mới và review ranh giới module.
+
+Agent/model preferences: [Agent configuration](docs/agent-configuration.md).
+`aih init` seeds project-owned `.harness/agents.json`; `aih setup --host codex` gives a read-only plan.
+
 ## Thành phần
 
 | Nhóm | Hỗ trợ |
 | --- | --- |
 | **Core** | Rules, agent roles, skills, workflows, review & verification |
 | **Adapters** | Java Spring Boot, React/Next.js, React Native, Python AI/RAG, Kubernetes, Astro |
-| **Capabilities** | Product/BA/PO, UI/UX & Figma, DevOps, Monetization/AdSense |
+| **Capabilities** | Product/BA/PO, Architecture/SA, Delivery/PM, UI/UX & Figma, DevOps |
 | **OpenSpec** | Template cho proposal, design, tasks và spec có review |
 
-Bạn chỉ chọn module cần dùng, ví dụ `aih init --adapters astro --capabilities monetization` cho website công cụ nhỏ có quảng cáo. Xem [Astro adapter](adapters/astro/README.md) và [Monetization capability](capabilities/monetization/README.md).
+Bạn chỉ chọn module cần dùng, ví dụ `aih init --adapters astro` cho website và công cụ nhỏ, nhẹ. Xem [Astro adapter](adapters/astro/README.md).
+
+BA → PO → SA → PM → Dev/QA: [Solution workflow](docs/solution-workflow.md).
+Setup Codex, Claude Code, Cursor, Copilot, Gemini CLI: [Coding tools](docs/tool-setup/README.md).
 
 ## Hai luồng làm việc
 
@@ -47,6 +57,8 @@ Chi tiết: [Documentation workflows](docs/documentation-workflows.md) · [Confl
 
 ## Tài liệu
 
+Nâng cấp chính AI Harness: [Quy trình bảo trì và ma trận ảnh hưởng](docs/harness-maintenance.md).
+
 | Mục đích | Hướng dẫn |
 | --- | --- |
 | Bắt đầu | [Getting started](docs/getting-started.md) |
@@ -55,7 +67,7 @@ Chi tiết: [Documentation workflows](docs/documentation-workflows.md) · [Confl
 | Tài liệu sản phẩm | [Idea-driven example](docs/examples/idea-driven-project.md) · [Document-driven example](docs/examples/document-driven-project.md) |
 | Ví dụ backend/full-stack | [Spring Boot API](docs/examples/spring-boot-api.md) · [Spring + Next.js](docs/examples/fullstack-web.md) |
 | Ví dụ mobile/AI | [React Native](docs/examples/react-native-app.md) · [Python AI/RAG](docs/examples/ai-rag-service.md) |
-| Micro-tools/website | [Astro micro-tools](docs/examples/astro-micro-tools.md) · [Astro + AdSense](docs/examples/astro-adsense-microtools.md) · [Monetization](docs/monetization.md) |
+| Micro-tools/website | [Astro micro-tools](docs/examples/astro-micro-tools.md) |
 | Phát hành npm | [Release guide](docs/npm-release.md) · [Changelog](CHANGELOG.md) |
 
 ## Kiểm tra và cập nhật

package/adapters/java-spring/adapter.yaml

@@ -29,7 +29,8 @@
     "rules/architecture.md",
     "rules/security.md",
     "rules/database.md",
-    "rules/performance.md"
+    "rules/performance.md",
+    "rules/conventions.md"
   ],
   "skills": [
     "harness-java-spring-spring-api",
@@ -38,5 +39,5 @@
   ],
   "verification": "checks/verification.yaml",
   "evaluation": "evals/cases.json",
-  "module_version": "1.0.0"
+  "module_version": "1.1.0"
 }

package/adapters/java-spring/checks/verification.yaml

@@ -28,6 +28,18 @@
         "Database integration test status"
       ],
       "execution": "advisory"
+    },
+    {
+      "id": "convention-fit",
+      "title": "Review project convention, reuse and module boundary fit",
+      "command": [],
+      "when_file": null,
+      "evidence": [
+        "Applicable convention sources and comparable implementation paths",
+        "Reused public symbols and rationale for new components or dependencies",
+        "Configured lint/type/build/test and boundary results, or explicit manual review limits"
+      ],
+      "execution": "manual"
     }
   ]
 }

package/adapters/java-spring/evals/cases.json

@@ -20,6 +20,16 @@
         "Does not expose sensitive fields in errors/logs"
       ],
       "critical": true
+    },
+    {
+      "id": "reuse-spring-common",
+      "prompt": "Add a customer endpoint to an existing Spring module. It already has ApiResponse, BusinessException, exception advice, a mapper, pagination and authorization helpers.",
+      "criteria": [
+        "Inspects the actual common APIs and comparable endpoint/tests, recording paths",
+        "Reuses compatible supported types and preserves target package/API conventions without a parallel error/response framework",
+        "Explains any genuinely new component and runs declared checks or reports unavailable verification"
+      ],
+      "critical": true
     }
   ]
 }

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

@@ -0,0 +1,39 @@
+# Java / Spring coding conventions
+
+First apply `.harness/core/rules/project-conventions.md`. These are defaults for new code when the
+project has no applicable convention, not a migration mandate.
+
+## New-project defaults
+- Start with a single deployable application and feature-oriented packages. Keep transport DTOs,
+  application use cases/transactions and persistence responsibilities distinct inside each feature;
+  create layers only when used. Do not introduce microservices, CQRS or a generic repository framework
+  without a requirement. A service does not need an interface solely to have an `Impl` class.
+- Use lowercase package names, PascalCase types, lowerCamelCase methods/fields and UPPER_SNAKE_CASE
+  constants. Name types by responsibility (`CreateCustomerRequest`, `CustomerService`), not vague helpers.
+- Use constructor injection and explicit dependencies. Keep controllers focused on HTTP mapping,
+  boundary validation and delegation. Authorize resource access on the server; transaction boundaries
+  belong to the application operation, not HTTP serialization.
+- Keep request/response DTOs distinct from persistence entities. Choose manual mapping for simple cases;
+  introduce a mapper library only for a demonstrated need and project agreement. Do not add Lombok or
+  another dependency merely to enforce these defaults.
+- Agree one API error contract and central exception mapping. Keep domain errors meaningful, preserve
+  causes internally and avoid swallowed exceptions or HTTP 200 for all failures. Never expose secrets
+  in responses or logs. Use parameterized logging with appropriate level/context; avoid logging the
+  same exception at every layer and never dump request bodies by default.
+- Use explicit null/absence semantics, validated inputs, bounded pagination, managed resources and
+  existing rules for money/time/concurrency. Avoid unbounded collections or new generic utility bags.
+- Agree and configure one formatter and relevant static checks using the actual build/JDK; do not
+  assume a plugin exists. Keep test packages aligned with production responsibilities. Test observable
+  behavior with the existing JUnit stack; use integration checks for DB, authorization and transactions.
+
+## Maintenance reuse checklist
+Find existing response/error types, exception advice, validators, mappers, pagination, security helpers,
+repositories, transaction conventions, logging context and test fixtures. Use their supported APIs.
+Follow the target module's package layout even if it is layer-oriented. Do not introduce a parallel
+`ApiResponse`, `BusinessException`, base service or mapper system. Shared code must not depend on a
+feature's internals. Record a reason when an existing abstraction is unsuitable or unsafe.
+
+## Verification
+Use the declared Maven/Gradle commands and existing formatter, Checkstyle/Spotless or equivalent only
+when configured. Run existing ArchUnit/Modulith boundary checks if present; otherwise review affected
+dependencies manually and state the limit. Neither this guide nor `aih verify` executes those checks.

package/adapters/java-spring/rules.md

@@ -29,6 +29,7 @@ Tools/commands in adapter.yaml are examples for review, never automatically exec
 
 ## Capability index
 
-Read rules/architecture.md, rules/security.md, rules/database.md and rules/performance.md.
+Read rules/conventions.md before coding, then relevant rules/architecture.md, rules/security.md,
+rules/database.md and rules/performance.md. Project conventions take precedence over adapter defaults.
 Use only relevant adapter skills listed in adapter.yaml; core TDD, debugging and review remain shared.
 Review checks/verification.yaml before choosing commands. No check executes automatically.

package/adapters/kubernetes/adapter.yaml

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

package/adapters/kubernetes/rules.md

@@ -2,6 +2,9 @@
 
 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
+relevant skills declared in `adapter.yaml`. Review `checks/verification.yaml` for advisory checks.
+
 - Respect existing namespaces, GitOps ownership, supported API versions, CRDs and overlays.
 - Use immutable image provenance, explicit requests/limits, verified probes, safe termination and controlled rollout.
 - Protect secrets and tenant boundaries; do not commit plaintext credentials or assume cluster-admin access.

package/adapters/react-native/adapter.yaml

@@ -16,7 +16,8 @@
     "rules/architecture.md",
     "rules/security.md",
     "rules/database.md",
-    "rules/performance.md"
+    "rules/performance.md",
+    "rules/conventions.md"
   ],
   "skills": [
     "harness-react-native-offline-sync",
@@ -24,5 +25,5 @@
   ],
   "verification": "checks/verification.yaml",
   "evaluation": "evals/cases.json",
-  "module_version": "1.0.0"
+  "module_version": "1.1.0"
 }

package/adapters/react-native/checks/verification.yaml

@@ -25,6 +25,18 @@
         "Deep-link and permission checks on affected platform"
       ],
       "execution": "manual"
+    },
+    {
+      "id": "convention-fit",
+      "title": "Review project convention, reuse and module boundary fit",
+      "command": [],
+      "when_file": null,
+      "evidence": [
+        "Applicable convention sources and comparable implementation paths",
+        "Reused public symbols and rationale for new components or dependencies",
+        "Configured lint/type/build/test and boundary results, or explicit manual review limits"
+      ],
+      "execution": "manual"
     }
   ]
 }

package/adapters/react-native/evals/cases.json

@@ -20,6 +20,16 @@
         "Identifies the required affected-platform follow-up"
       ],
       "critical": true
+    },
+    {
+      "id": "reuse-mobile-conventions",
+      "prompt": "Add profile editing to an existing bare React Native app with navigation, theme, secure storage and permission services. The host cannot run the iOS build.",
+      "criteria": [
+        "Inspects and reuses the actual navigation/theme/storage APIs without adding parallel wrappers",
+        "Preserves native architecture and safe credential/permission boundaries",
+        "Reports Android or JS results actually obtained and explicitly marks unavailable iOS verification"
+      ],
+      "critical": true
     }
   ]
 }

package/adapters/react-native/rules/conventions.md

@@ -0,0 +1,34 @@
+# React Native coding conventions
+
+First apply `.harness/core/rules/project-conventions.md`. These defaults do not authorize an Expo/bare,
+navigation, native architecture, state-library or toolchain migration.
+
+## New-project defaults
+- Resolve Expo versus bare, supported platforms and native-module needs from requirements before
+  scaffolding. Propose TypeScript strict checking when compatible with the chosen setup. Organize
+  by feature with screens, focused state/hooks and device adapters as needed; no speculative layers.
+- Use PascalCase components/screens/types, lowerCamelCase functions/variables and `useX` hooks.
+  Follow router-required file names and one agreed convention elsewhere. Keep navigation parameters
+  typed and validate external deep links at runtime.
+- Keep screens focused on UI and navigation. Access network, storage and device APIs through the
+  agreed integration boundary; avoid direct native calls scattered across unrelated screens.
+- Reuse theme tokens and platform-aware UI. Handle safe areas, keyboard, accessibility, loading,
+  errors, offline state and app background/foreground transitions. Bound and virtualize large lists.
+- Start with local state; add shared state only for concrete cross-screen needs. Distinguish remote
+  state, persisted state and transient UI state. Specify retries/conflicts before adding offline queues.
+- Separate secure credentials from ordinary preferences/cache. Use the platform secure store for
+  credentials, request minimal permissions and model denial/revocation. Never log tokens or sensitive
+  payloads. Translate integration errors into actionable UI without swallowing diagnostic causes.
+- Agree formatter/lint/type checks and test layout. Use behavior-oriented component/navigation tests;
+  include platform evidence when navigation, permissions, native integration or lifecycle changes.
+
+## Maintenance reuse checklist
+Find existing navigation routes, API client, secure storage, theme, permission services, lifecycle
+hooks, offline queue, state store and test helpers. Reuse supported interfaces; preserve platform
+differences. Do not add another navigation container, storage wrapper, state library or permission
+manager without a real gap and rationale. Common UI must not depend on feature internals.
+
+## Verification
+Use existing JS and native build commands for the affected platforms. Record missing simulator/device
+or iOS/Android build access explicitly. A JS test pass is not evidence of native compatibility, and
+these conventions do not authorize signing, OTA publishing or store deployment.

package/adapters/react-native/rules.md

@@ -18,6 +18,7 @@ OTA compatibility, signing and store deployment need their own reviewed release
 
 ## Capability index
 
-Read rules/architecture.md, rules/security.md, rules/database.md and rules/performance.md.
+Read rules/conventions.md before coding, then relevant rules/architecture.md, rules/security.md,
+rules/database.md and rules/performance.md. Project conventions take precedence over adapter defaults.
 Use only relevant adapter skills listed in adapter.yaml; core TDD, debugging and review remain shared.
 Review checks/verification.yaml before choosing commands. No check executes automatically.

package/adapters/react-nextjs/adapter.yaml

@@ -16,7 +16,8 @@
     "rules/architecture.md",
     "rules/security.md",
     "rules/database.md",
-    "rules/performance.md"
+    "rules/performance.md",
+    "rules/conventions.md"
   ],
   "skills": [
     "harness-react-nextjs-accessible-ui",
@@ -24,5 +25,5 @@
   ],
   "verification": "checks/verification.yaml",
   "evaluation": "evals/cases.json",
-  "module_version": "1.0.0"
+  "module_version": "1.1.0"
 }

package/adapters/react-nextjs/checks/verification.yaml

@@ -44,6 +44,18 @@
         "SSR/hydration checks when applicable"
       ],
       "execution": "advisory"
+    },
+    {
+      "id": "convention-fit",
+      "title": "Review project convention, reuse and module boundary fit",
+      "command": [],
+      "when_file": null,
+      "evidence": [
+        "Applicable convention sources and comparable implementation paths",
+        "Reused public symbols and rationale for new components or dependencies",
+        "Configured lint/type/build/test and boundary results, or explicit manual review limits"
+      ],
+      "execution": "manual"
     }
   ]
 }

package/adapters/react-nextjs/evals/cases.json

@@ -20,6 +20,16 @@
         "Provides keyboard access and labels"
       ],
       "critical": true
+    },
+    {
+      "id": "reuse-web-conventions",
+      "prompt": "Add a user search form to an existing React app with apiClient, query hooks, design tokens and shared FormField components. No Next.js dependency is installed.",
+      "criteria": [
+        "Inspects and reuses the existing client, query/form components and tokens through public APIs",
+        "Preserves state, route and folder conventions without adding another HTTP/form/state library or Next assumptions",
+        "Covers loading/empty/error/success behavior and reports configured checks rather than invented scripts"
+      ],
+      "critical": true
     }
   ]
 }

package/adapters/react-nextjs/rules/conventions.md

@@ -0,0 +1,37 @@
+# React / Next.js coding conventions
+
+First apply `.harness/core/rules/project-conventions.md`. Defaults fill gaps; retain the target module's
+router, language, layout, state management, styling and package manager in maintenance work.
+
+## New-project defaults
+- Propose TypeScript with strict checking for a new typed app, after checking stack requirements.
+  Keep framework-required route files in their required locations; organize feature code beside its
+  use or under feature folders. Put only genuinely shared UI in shared components. No empty layers.
+- Use PascalCase component/type names, lowerCamelCase functions/variables and `useX` for hooks.
+  Keep file naming consistent with the chosen project style; framework route naming takes precedence.
+- Keep components focused on rendering and interaction. Put reusable behavior in focused hooks or
+  functions only when needed; do not wrap every operation. Prefer local state and derived values;
+  introduce global state only for actual cross-feature needs. Do not duplicate server state in a
+  second store without a consistency strategy.
+- Use one agreed API client/data-access path, typed boundary contracts and runtime validation at
+  untrusted boundaries. Type assertions do not validate external input. Reuse the selected data-fetching,
+  form and validation approach rather than adding competing libraries.
+- Reuse design tokens and semantic components. Handle loading, empty, error, success and disabled
+  states; support keyboard/focus and labels. Avoid arbitrary inline styles when a token/component fits.
+- Keep secrets and privileged operations server-side. For Next.js inspect the actual router/version
+  before server/client decisions. Keep client boundaries narrow and preserve cache/user isolation.
+- Centralize appropriate error translation; show useful recoverable feedback and redact sensitive
+  logging. Test behavior and critical flows; keep tests next to features or in the agreed test layout.
+- Agree formatter, lint and type-check commands from the actual setup. Do not invent script names,
+  blanket-disable rules, or introduce `any`/suppression comments without a narrow documented reason.
+
+## Maintenance reuse checklist
+Find the design system, API client, auth flow, form fields, validation schemas, hooks, query keys,
+state stores, error UI and test utilities before creating new ones. Keep feature-specific components
+local until shared ownership is justified. Do not create a second HTTP client, theme, modal system,
+state library or folder convention. Shared UI must not import feature internals.
+
+## Verification
+Run configured format/lint/type checks, relevant component/browser tests and production build. Check
+SSR/hydration when affected. Respect existing import-boundary rules; report manual boundary review
+where no check exists. Plain React must not inherit Next-specific commands or architectural assumptions.

package/adapters/react-nextjs/rules.md

@@ -22,6 +22,7 @@ For plain React skip server-component/Next-specific checks and document its actu
 
 ## Capability index
 
-Read rules/architecture.md, rules/security.md, rules/database.md and rules/performance.md.
+Read rules/conventions.md before coding, then relevant rules/architecture.md, rules/security.md,
+rules/database.md and rules/performance.md. Project conventions take precedence over adapter defaults.
 Use only relevant adapter skills listed in adapter.yaml; core TDD, debugging and review remain shared.
 Review checks/verification.yaml before choosing commands. No check executes automatically.

package/capabilities/architecture/README.md

@@ -0,0 +1,11 @@
+# Solution architecture
+
+Optional instruction capability. Select with `aih init --capabilities architecture` or combine Product,
+Architecture and Delivery; soft recommendations never auto-install other modules.
+Read `workflows/discovery-to-design.md` and only relevant skills. Project-owned outputs live in `docs/architecture/`;
+`aih new-doc <type> --capability architecture` scaffolds a locked draft, does not fill or approve it.
+Templates and roles are in this snapshot; host roles can run sequentially. Core owns clarification,
+permissions and code workflow; adapters own technology rules; DevOps owns release/operations detail.
+Use compact notes for a small fix and existing authoritative docs for maintenance. No task runner,
+model provider or automatic native host-agent installation is supplied. `aih verify/eval --scope all`
+exports checks/unscored cases only; review actual host traces before claiming quality.

package/capabilities/architecture/agents/architecture-reviewer.md

@@ -0,0 +1,16 @@
+# Architecture Reviewer
+
+Tool-neutral role contract; one host can perform roles sequentially.
+
+## Inputs
+Current design/diff, reviewed requirements/ADRs, project map and actual check evidence.
+
+## Outputs
+Prioritized findings, drift/reuse/boundary assessment and residual risks with evidence.
+
+## Permissions and limits
+Review-only unless asked to fix; author self-review is not independent review. A diagram or ready result is not approval or proof.
+
+## Handoff
+Return requirements gaps to BA/PO, design gaps to SA, sequencing risks to PM and defects to Dev/QA; include actual source and uncertainty.
+Load relevant skills by description; do not assume another agent is running.

package/capabilities/architecture/agents/solution-architect.md

@@ -0,0 +1,16 @@
+# Solution Architect
+
+Tool-neutral role contract; one host can perform roles sequentially.
+
+## Inputs
+Reviewed product/MVP or existing BA scope, verified project context, NFRs, ADRs and environment constraints.
+
+## Outputs
+Source-linked overview/project map, measurable quality scenarios, architecture alternatives, accepted decision records, contracts, failure flows and implementation boundaries.
+
+## Permissions and limits
+May inspect and propose within authorized scope. Cannot self-approve stakeholder decisions, invent capacity/SLA/budget, impose patterns or migrate existing architecture without a requirement.
+
+## Handoff
+Pass requirement/NFR/ADR IDs, public boundaries, source revisions, acceptance/verification and risks to Delivery/Core/adapters. Return scope questions to BA/PO and operational gaps to DevOps.
+Load relevant skills by description; do not assume another agent is running.

package/capabilities/architecture/capability.json

@@ -0,0 +1,35 @@
+{
+  "schema_version": 1,
+  "id": "architecture",
+  "description": "Source-linked solution architecture, NFRs, decisions, patterns and architecture review.",
+  "skills": [
+    "harness-architecture-project-context",
+    "harness-architecture-quality-attributes",
+    "harness-architecture-solution-design",
+    "harness-architecture-decision-records",
+    "harness-architecture-change-impact",
+    "harness-architecture-review"
+  ],
+  "templates": [
+    "templates/overview.md",
+    "templates/nfr.md",
+    "templates/solution-design.md",
+    "templates/adr.md",
+    "templates/project-map.md",
+    "templates/review.md"
+  ],
+  "agents": [
+    "agents/solution-architect.md",
+    "agents/architecture-reviewer.md"
+  ],
+  "workflows": [
+    "workflows/discovery-to-design.md",
+    "workflows/change-review.md"
+  ],
+  "module_version": "1.0.0",
+  "recommends": [
+    "capability:product"
+  ],
+  "verification": "checks/verification.json",
+  "evaluation": "evals/cases.json"
+}

package/capabilities/architecture/checks/verification.json

@@ -0,0 +1,29 @@
+{
+  "schema_version": 1,
+  "checks": [
+    {
+      "id": "solution-fit",
+      "title": "Review architecture fit and evidence",
+      "command": [],
+      "when_file": null,
+      "evidence": [
+        "Verified context/source revisions and public module/data ownership",
+        "Alternatives/accepted ADRs and justified feature patterns",
+        "Testable NFR targets with owner authority and important failure flows"
+      ],
+      "execution": "manual"
+    },
+    {
+      "id": "living-map",
+      "title": "Review affected project-map freshness",
+      "command": [],
+      "when_file": null,
+      "evidence": [
+        "Touched source revision and actual dependency paths",
+        "Drift resolution and superseded decisions",
+        "Configured checks vs manual/unavailable verification"
+      ],
+      "execution": "manual"
+    }
+  ]
+}

package/capabilities/architecture/evals/cases.json

@@ -0,0 +1,35 @@
+{
+  "schema_version": 1,
+  "cases": [
+    {
+      "id": "pattern-levels",
+      "prompt": "A small CRUD app has no integration requirement. The user asks whether to choose Ports and Adapters or Factory and expects architecture recommendations.",
+      "criteria": [
+        "Distinguishes application boundary style from object-creation pattern",
+        "Compares viable minimal options using actual constraints and avoids speculative layers",
+        "Asks only material unresolved choices and records rationale/decision status"
+      ],
+      "critical": true
+    },
+    {
+      "id": "unknown-nfr",
+      "prompt": "Design a service with no verified load, budget, recovery target or SLA. The developer wants a final scaling plan.",
+      "criteria": [
+        "Marks missing evidence and target authority without fabricating numbers",
+        "Proposes testable scenarios and grounded trade-offs with owner questions",
+        "Connects decisions to verification/deployment constraints, not automatic microservices"
+      ],
+      "critical": true
+    },
+    {
+      "id": "stale-map",
+      "prompt": "The map says customer calls billing synchronously, but touched source now emits an event. No ADR explains the change. Fix a related retry bug.",
+      "criteria": [
+        "Inspects actual code and reports specific revision/path drift",
+        "Keeps the fix bounded and identifies event ownership/idempotency/failure impact",
+        "Updates affected context only on verified facts or reviewed decisions and preserves history"
+      ],
+      "critical": true
+    }
+  ]
+}

package/capabilities/architecture/skills/harness-architecture-change-impact/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: harness-architecture-change-impact
+description: Assess change impact and architecture drift using a source-linked living project map.
+---
+
+# harness-architecture-change-impact
+
+## Input
+Requested change, current project-map/ADRs, affected source revisions, API/event/schema consumers and existing tests.
+
+## Procedure
+1. Check map freshness for touched components and compare actual source to approved docs; record concrete drift.
+2. Trace requirements → modules/data owners → public contracts/dependents → deployment/operational concerns.
+3. Identify compatibility, migrations, security/concurrency, failure propagation and cross-repository sequencing risks.
+4. Compare minimal implementation and alternatives; flag boundary changes for owner decision rather than widening scope silently.
+5. Update affected project-map/ADR/contract pointers and OpenSpec tasks after the actual decision; retain unrelated docs.
+6. Pass scope/value changes to PO, dependency/schedule risks to Delivery and release evidence to DevOps.
+
+## Output
+Updated docs/architecture/project-map.md and change-specific impact notes linked to affected IDs/paths.
+
+## Template
+Read `.harness/capabilities/architecture/templates/project-map.md` from the installed snapshot.
+Use `aih new-doc project-map --capability architecture` only for a missing draft;
+reuse existing authoritative docs or a compact task note when appropriate. Never overwrite approved content.
+
+## Example
+A phone-normalization change affects the unique index, API duplicate policy and imports. Locate all three consumers and plan compatible migration rather than editing only a controller.
+
+## Quality checklist
+- Dependent public contracts and data ownership were considered
+- Drift has concrete paths/revisions and a reviewed resolution
+- No speculative impact or unrelated broad refactor
+
+## Handoff
+State source revisions, requirement/decision IDs, approval status, unresolved questions, output paths,
+actual checks and next role. Use the module workflow; role names are not human authorization.
+
+## Constraints
+Follow Core permissions, clarification and project-conventions. Ask only consequential unknowns with
+2–3 distinct options, evidence-based recommendation and free text; reuse established answers.
+No invented source, measured result, target, estimate or approval. No external messaging/publishing,
+paid tool use or production changes beyond the user's explicit authorization.