@manhd_d/ai-harness 0.7.0 → 0.9.0

package/CHANGELOG.md

@@ -1,5 +1,41 @@
 # Changelog
 
+## Unreleased — Simpler onboarding
+- Consolidate first-use documentation into a one-command README and a copyable AI task; keep setup and model preferences optional.
+- Add docs/README.md for advanced guides and examples, preserving frontend/mobile onboarding and environment ownership from the latest main.
+- Verify documentation discovery through the index. No CLI, module or consumer schema changes.
+
+## Unreleased — Frontend/mobile coding and onboarding
+- Simplify init/host onboarding and surface current CLI flags in the command table.
+- Add focused React/Next.js feature/testing and React Native screen/testing skills with examples, quality and handoffs; each adapter module advances to 1.2.0.
+- Connect manifests, discovery, manual checks/unscored scenarios, skill matrix, stack examples and package/install/update tests. No application runner, library migration or native verification claim.
+
+
+## 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 +95,27 @@
 - Check release metadata consistency and establish single-release-PR version discipline; retain v0.6.0 until a dedicated release PR.
 
 
+## [0.9.0](https://github.com/manh0303/ai-harness/compare/v0.8.0...v0.9.0) (2026-10-13)
+
+
+### Features
+
+* complete onboarding and web mobile coding skills ([4e26a1d](https://github.com/manh0303/ai-harness/commit/4e26a1de1d5c2c95a6b4a6c610ebc4d6ccad61f6))
+
+## [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

@@ -1,76 +1,38 @@
 # AI Harness
 
-**Bộ quy tắc, skills và workflows tái sử dụng để AI hỗ trợ phát triển phần mềm theo quy trình _Spec → Code → Test → Review_.**
+**Giúp AI làm việc theo quy tắc của project: hiểu yêu cầu → viết code → test → review.**
 
-AI Harness cài context vào từng repository qua CLI `aih`. Có thể kết hợp các technology adapters và capabilities theo nhu cầu; không phụ thuộc một IDE hay mô hình AI cụ thể.
+Dùng với Codex, Claude Code, Cursor và các AI coding tools đọc được file trong project.
 
-> Yêu cầu **Node.js 22+**. CLI không tự chạy LLM, viết code, phê duyệt tài liệu, merge PR hoặc deploy.
+## Bắt đầu
 
-## Cài đặt và dùng nhanh
+Cần **Node.js 22+**. Chạy trong thư mục project của bạn:
 
 ```bash
-npm install -g @manhd_d/ai-harness
-
-# Chạy trong một project đã tồn tại
-aih init --adapters java-spring
-aih check
-aih setup
+npx --yes @manhd_d/ai-harness init --detect
 ```
 
-Tiếp theo, ghi stack, nghiệp vụ và lệnh test vào `.harness/local.md`; mở project trong AI IDE và yêu cầu assistant đọc `AGENTS.md` trước khi làm việc. Bạn giao task bình thường, AI đọc skill liên quan và báo cáo test thực chạy.
-
-Thêm `--capabilities product` khi cần tài liệu BA; `aih new-doc prd-lite` tạo template, `aih new-change <id>` tạo spec nháp khi cần. Không bắt mọi task tạo đủ tài liệu. Xem [Getting started](docs/getting-started.md) và [CLI reference](docs/cli.md).
-
-**Phân biệt:** `aih check` kiểm tra file Harness; `aih verify` xuất checklist; build/test ứng dụng do AI host hoặc CI thực chạy. CLI không bảo đảm AI sẽ tuân thủ hướng dẫn; xem [đánh giá hành vi](evals/README.md).
-
-`aih setup` đưa gợi ý câu hỏi cho AI host; AI hỏi phần còn mơ hồ bằng A/B/C có đề xuất và lưu câu trả lời.
-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).
-
-## Thành phần
+Mở project trong công cụ AI bạn dùng, rồi gửi:
 
-| 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 |
-| **OpenSpec** | Template cho proposal, design, tasks và spec có review |
+> Đọc AGENTS.md, khảo sát project và ghi context cần thiết vào .harness/local.md.
+> Thực hiện yêu cầu: [mô tả công việc]. Chạy test phù hợp và báo cáo kết quả.
 
-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 giao việc bình thường, không cần gọi từng agent, skill hay mở chat riêng cho từng vai. Harness cài hướng dẫn; công cụ AI thực hiện công việc.
+`--detect` nhận diện stack từ file ở thư mục gốc; nếu báo chưa nhận diện được, chọn stack theo [hướng dẫn bắt đầu](docs/getting-started.md).
 
-## Hai luồng làm việc
+## Chọn theo nhu cầu
 
-- **Idea-driven:** Ý tưởng → thảo luận/nghiên cứu → BRD/PRD/SRS → UI/UX → spec → code.
-- **Document-driven:** BRD/PRD/SRS/Confluence đã có → phân tích gap → technical spec → code.
+- **Code:** Spring Boot, React/Next.js, React Native, Python AI/RAG, Astro, Kubernetes.
+- **Tài liệu:** từ ý tưởng hoặc tài liệu BA đã có đến yêu cầu và kế hoạch triển khai.
+- **Mở rộng:** UI/UX, kiến trúc, quản lý tiến độ, DevOps khi cần.
 
-Chi tiết: [Documentation workflows](docs/documentation-workflows.md) · [Confluence integration](integrations/confluence/README.md).
+Chỉ cài phần cần dùng. Task nhỏ không cần đủ BRD/PRD/SRS hay spec.
 
 ## Tài liệu
 
-| Mục đích | Hướng dẫn |
-| --- | --- |
-| Bắt đầu | [Getting started](docs/getting-started.md) |
-| Phát triển end-to-end | [Full SDLC](docs/end-to-end-workflow.md) · [Agent handoffs](docs/agent-handoffs.md) |
-| Tra cứu kỹ năng | [Skill matrix](docs/skill-matrix.md) · [CLI reference](docs/cli.md) |
-| 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) |
-| Phát hành npm | [Release guide](docs/npm-release.md) · [Changelog](CHANGELOG.md) |
+[Bắt đầu & chọn stack](docs/getting-started.md) · [Tra cứu & ví dụ](docs/README.md) · [Cấu hình công cụ AI](docs/tool-setup/README.md)
 
-## Kiểm tra và cập nhật
-
-```bash
-# Trong repository AI Harness (maintainer)
-npm test
-npm run validate
-npm run test:package
-
-# Nâng CLI global, rồi cập nhật snapshot trong project
-npm install -g @manhd_d/ai-harness@latest
-aih update --dry-run
-aih update
-aih check
-```
+`aih check` chỉ kiểm tra file Harness; tính năng đúng hay chưa cần test của project và review.
 
-**License:** [MIT](LICENSE). GitHub source có thể private; package `@manhd_d/ai-harness` được phát hành công khai qua npm.
+Đóng góp: [Contributing](CONTRIBUTING.md) · [Bảo trì Harness](docs/harness-maintenance.md).
+License: [MIT](LICENSE).

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,13 +16,16 @@
     "rules/architecture.md",
     "rules/security.md",
     "rules/database.md",
-    "rules/performance.md"
+    "rules/performance.md",
+    "rules/conventions.md"
   ],
   "skills": [
     "harness-react-native-offline-sync",
-    "harness-react-native-device-permissions"
+    "harness-react-native-device-permissions",
+    "harness-react-native-screen-delivery",
+    "harness-react-native-behavior-testing"
   ],
   "verification": "checks/verification.yaml",
   "evaluation": "evals/cases.json",
-  "module_version": "1.0.0"
+  "module_version": "1.2.0"
 }

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

@@ -25,6 +25,42 @@
         "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"
+    },
+    {
+      "id": "feature-slice",
+      "title": "Review route/screen, data/state and existing public API fit",
+      "command": [],
+      "when_file": null,
+      "evidence": [
+        "AC to route/screen, interaction and API/state mapping",
+        "Reused component/client/form/router APIs and justified new code",
+        "Validation, loading/error/pending states and stale/account response handling"
+      ],
+      "execution": "manual"
+    },
+    {
+      "id": "behavior-evidence",
+      "title": "Review actual behavior checks and environment limits",
+      "command": [],
+      "when_file": null,
+      "evidence": [
+        "AC-linked component/integration results and simulated boundaries",
+        "Separate JS, iOS/Android build and simulator/device evidence",
+        "Confirmed scripts, actual results and owner for unavailable checks"
+      ],
+      "execution": "manual"
     }
   ]
 }

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

@@ -20,6 +20,36 @@
         "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
+    },
+    {
+      "id": "screen-slice",
+      "prompt": "Add profile editing to a bare React Native app using its existing navigator, theme, query client and fields. Logout may occur while saving. Do not add dependencies; iOS access is unavailable.",
+      "criteria": [
+        "Reuses actual navigator/theme/client/form APIs without Expo or competing wrappers",
+        "Handles pending/validation/expiry/back and previous-account asynchronous data boundaries",
+        "Maps the slice to behavior checks and records JS/Android evidence separately from blocked iOS checks"
+      ],
+      "critical": true
+    },
+    {
+      "id": "test-boundaries",
+      "prompt": "Verify logout/account switching during an in-flight profile request and keyboard behavior on iOS and Android. Only JS tests with mocked native modules are available.",
+      "criteria": [
+        "Uses observable screen/navigation assertions and deterministic old-account responses",
+        "Records mocked JS boundaries separately from device/keyboard/native behavior",
+        "Keeps both platform/device checks blocked with follow-up and does not infer native success"
+      ],
+      "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,10 @@ 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.
+Use harness-react-native-screen-delivery for screen/navigation/API/state slices and
+harness-react-native-behavior-testing for JS/platform/device evidence. Load offline-sync or
+device-permissions only when that behavior is touched; keep missing native verification explicit.
 Review checks/verification.yaml before choosing commands. No check executes automatically.

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

@@ -0,0 +1,48 @@
+---
+name: harness-react-native-behavior-testing
+description: Verify React Native and Expo screens using existing JavaScript, navigation and device tests. Use for forms, auth/account transitions, lifecycle, permissions/offline regressions or changes requiring separate iOS and Android evidence.
+---
+
+# Mobile behavior testing
+
+## Input
+Changed screen/AC, actual test scripts/runner and navigation setup, affected platforms, native/device
+access, and existing API/storage/permission fixtures.
+
+## Procedure
+1. Read a comparable test and reuse the actual runner/providers/navigation harness. Map risks to pure
+   logic, component/navigation integration, native build and simulator/device checks.
+2. Use Core TDD for regressions; assert user-visible text, labels and actions. Cover relevant form errors,
+   pending/success/failure, expiry and stale requests. Control external API/storage/native dependencies;
+   state exactly which behavior is simulated rather than actually run on a device.
+3. Keep screen modules and navigation connected where practical. Exercise back/cancel, auth transitions,
+   logout/account changes and absence of previous-account data. For offline/permission changes test
+   reconnect/retry/conflict or denial/revocation using the selected specialized skill and approved contract.
+4. Check affected iOS/Android builds and critical simulator/device flows when access exists: keyboard,
+   safe area, accessibility, background/resume and cold/warm links as applicable. Reuse an existing E2E
+   runner rather than installing one by default. A JS mock cannot establish native-module correctness.
+5. Run confirmed targeted tests and configured lint/type checks. Record platform/runtime, command,
+   result and mocked boundaries; label missing native builds/devices blocked with follow-up owner.
+
+## Output
+AC → JS/navigation/native/device evidence matrix, meaningful regression tests, actual results,
+mock scope and explicit blocked checks. Keep UI smoke, build and real device evidence distinct.
+
+## Example
+For logout during an in-flight profile request, complete the old request after logout and assert that
+the next account never sees previous-account data. If only JS tests can run, report those results;
+Android/iOS build and device checks remain blocked, not implicitly passed.
+
+## Quality checklist
+- Test observable screen/navigation outcomes, not only snapshots or internal props/state.
+- Isolate credentials/cache/time/network fixtures and cover relevant failure/lifecycle paths.
+- Distinguish mocks, simulator/device behavior and per-platform build results.
+- Give every blocked native check a concrete follow-up; do not invent scripts or passing output.
+
+## Constraints
+Do not call production APIs, change signing, publish OTA/store artifacts or infer native compatibility
+from Node.js component tests. Keep existing tooling and Core permission/review gates.
+
+## Handoff
+Pass AC/test/source paths, actual failures/results, device/toolchain needs and affected platforms to
+Implementer/Reviewer. The Harness emits instructions/checklists; the authorized host runs actual tests.

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

@@ -0,0 +1,53 @@
+---
+name: harness-react-native-screen-delivery
+description: Implement React Native or Expo screens with existing navigation, forms, API/state and platform conventions. Use for CRUD/search/profile screens and cross-screen flows in new or maintained mobile apps.
+---
+
+# Mobile screen delivery
+
+## Input
+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.
+
+## Procedure
+1. Apply `.harness/core/rules/project-conventions.md` and selected adapter rules. Inspect a comparable
+   screen and public navigation/UI/client/state APIs. Preserve Expo/bare, native architecture and
+   existing router; ask only consequential unresolved platform or business choices with recommendations.
+2. Plan one route → screen → data operation slice. Use the existing typed navigation contract and
+   validate external parameters. Preserve auth transitions/back behavior; hiding a screen is not backend
+   authorization. Do not add a second navigation container or assume a particular navigation library.
+3. Reuse form/input and API/query boundaries. Distinguish transient, remote and persisted state; avoid
+   copying remote data into another store. Handle loading, empty, validation, failed/pending/success writes,
+   token expiry and stale responses after navigation or account switching.
+4. Use theme tokens and appropriate platform behavior: safe areas, keyboard/input visibility, accessible
+   labels/focus, back/cancel and long-list rendering. Handle focus/background/foreground requests with
+   the existing lifecycle abstraction; prevent old-account responses from restoring cleared data.
+5. Load `.agents/skills/harness-react-native-offline-sync/SKILL.md` only for persistence/replay/conflicts;
+   use `.agents/skills/harness-react-native-device-permissions/SKILL.md` when permissions/deep links change.
+   Keep credentials in the existing secure store and ordinary cache under the approved data policy.
+6. Use Core TDD/review and `.agents/skills/harness-react-native-behavior-testing/SKILL.md`. Record
+   JS/build/device evidence per affected platform and missing toolchain/device access.
+
+## Output
+Screen diff, AC → navigation/UI → API/state → tests mapping, reused public APIs and new-code rationale;
+platform-specific evidence and unresolved business/native decisions.
+
+## Example
+For profile editing in a bare app, reuse its navigator, FormField, client/query and theme. Handle pending
+save, server validation, expiry and back/cancel; do not convert to Expo or add an offline queue.
+An illustrative handoff reports JS tests actually run and missing iOS device access separately.
+
+## Quality checklist
+- Preserve navigation/auth/account boundaries and guard stale asynchronous results.
+- Verify keyboard/safe-area/accessibility and affected lifecycle states on supported platforms.
+- Reuse existing storage/client/state APIs; explain new abstractions and data retention.
+- Report iOS/Android/JS results separately with blocked checks and next owner.
+
+## Constraints
+Do not assume new native modules, permissions, offline behavior or signing are needed. A task does not
+authorize a toolchain/router migration, OTA publication or store deployment. Do not claim native success
+from JavaScript tests or bypass backend validation/authorization.
+
+## Handoff
+Pass AC IDs, source/public APIs, route/state decisions, actual platform evidence and remaining checks
+to Reviewer/Test Engineer. Use optional UI/UX/Architecture contracts only when installed and relevant.

package/adapters/react-nextjs/adapter.yaml

@@ -16,13 +16,16 @@
     "rules/architecture.md",
     "rules/security.md",
     "rules/database.md",
-    "rules/performance.md"
+    "rules/performance.md",
+    "rules/conventions.md"
   ],
   "skills": [
     "harness-react-nextjs-accessible-ui",
-    "harness-react-nextjs-server-boundaries"
+    "harness-react-nextjs-server-boundaries",
+    "harness-react-nextjs-feature-delivery",
+    "harness-react-nextjs-behavior-testing"
   ],
   "verification": "checks/verification.yaml",
   "evaluation": "evals/cases.json",
-  "module_version": "1.0.0"
+  "module_version": "1.2.0"
 }

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

@@ -44,6 +44,42 @@
         "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"
+    },
+    {
+      "id": "feature-slice",
+      "title": "Review route/screen, data/state and existing public API fit",
+      "command": [],
+      "when_file": null,
+      "evidence": [
+        "AC to route/screen, interaction and API/state mapping",
+        "Reused component/client/form/router APIs and justified new code",
+        "Validation, loading/error/pending states and stale/account response handling"
+      ],
+      "execution": "manual"
+    },
+    {
+      "id": "behavior-evidence",
+      "title": "Review actual behavior checks and environment limits",
+      "command": [],
+      "when_file": null,
+      "evidence": [
+        "AC-linked component/integration results and simulated boundaries",
+        "Actual browser/server evidence or explicit blocked checks",
+        "Confirmed scripts, actual results and owner for unavailable checks"
+      ],
+      "execution": "manual"
     }
   ]
 }