merge(main): merge v2.7.0 release from develop

.agents/skills/nexent-python-tests/SKILL.md

@@ -1,12 +1,14 @@
 ---
 name: nexent-python-tests
-description: Use when writing, debugging, or reviewing Nexent Python unit tests under test/backend, test/sdk, or other test Python modules. Covers pytest fixtures, lookup-site mocking, async behavior, isolation, and regression assertions. Skip frontend checks and live-service functional or model-runtime verification.
+description: Maintain the legacy implementation-oriented Nexent Python unit tests under test/backend, test/sdk, and test/ext_components. Use for pytest fixtures, lookup-site mocking, async behavior, isolation, and regression assertions in those existing suites. Do not create or maintain the requirement-driven D1-D5 baseline, automation, or manifest.
 ---
 
-# Nexent Python unit tests
+# Nexent legacy Python unit tests
 
 Paths below are relative to the repository root.
 
+These tests are a legacy suite kept separate from the requirement-driven D1-D5 system. Do not assign formal D1-D5 case IDs to them, add them to `test/manifests/d1-d5.yaml`, or count them in the generated functional baseline. Use `nexent-test-assets` for new D1-D5 work.
+
 1. Identify the unit and behavior. Inspect neighboring tests, `test/conftest.py`, and `test/pytest.ini` before changing fixture/import setup.
 2. Use pytest exclusively, pytest assertions, fixtures, and `pytest-mock`. Files/functions start with `test_`; test classes start with `Test`. Keep files below 500 lines or split by feature using `test_<module>_<feature>.py`; split package directories include `__init__.py`.
 3. Import the unit and necessary test helpers. Mock collaborators rather than exercising external interfaces/clients/services. Patch the fully qualified lookup site determined from actual imports, not the dependency's definition module.

.agents/skills/nexent-spec-coding/SKILL.md

@@ -1,73 +1,67 @@
 ---
 name: nexent-spec-coding
-description: Run document-driven SPEC development for Nexent features, fixes, refactors, APIs, UI, internal logic, and model or Agent runtime changes. Use with the Git-managed nexent code repository and its separate sibling nexent-doc repository when work requires reviewed requirements, test-first implementation, functional verification, and acceptance evidence.
+description: Run the Nexent requirement or bug lifecycle from SPEC analysis through feature catalog and D1-D5 case design, product implementation, fixed test implementation, local verification, and delivery evidence. Use for features, fixes, refactors, APIs, UI, and model or Agent runtime changes.
 ---
 
 # Nexent SPEC Coding
 
-Develop Nexent from an approved SPEC and produce evidence for every acceptance criterion.
+Develop Nexent from an evidence-backed SPEC while keeping product behavior, formal D1-D5 test assets, implementation, and verification synchronized.
 
 ## Repository boundaries
 
-- Treat `nexent/` as the Git-managed code repository and its sibling `nexent-doc/` as the document repository.
-- Never run Git commands in the document repository or move SPEC documents into the code repository.
-- Search and reuse existing feature specifications before creating a new one. Name each new SPEC or change directory from the canonical registry at `<document-repository>/docs/Developing/spec-module-abbreviations.md`: `<level-1>-<level-2>-<2-to-5-feature-words>`, or `<level-1>-<2-to-5-feature-words>` when level 2 is omitted. Keep `proposal.md`, `design.md`, `task.md`, and `delta-spec.md` as fixed artifact names inside that directory.
-- Preserve unrelated changes. Record the initial code branch/status, applicable repository instructions, build configuration, and test layout.
+- Treat `nexent/` as the Git-managed product repository and its sibling `nexent-doc/` as the document repository.
+- Never run Git commands in the document repository or move SPEC documents into the product repository.
+- Preserve unrelated changes. Record the initial branch/status, applicable repository instructions, build configuration, and test layout.
+- Keep the existing tests under `test/backend`, `test/sdk`, and `test/ext_components` as Legacy UT. Do not map them into the formal D1-D5 manifest.
 
 ## Read the right references
 
-Select the document mode with [spec-maintenance-guide.md](references/spec-maintenance-guide.md): create a requirement-scoped SPEC for new features and refactors; update a usable baseline or add a delta for a bug fix; reconstruct the owning feature from code and tests when no usable baseline exists. Omit uncertain peripheral detail, but resolve uncertainty that affects the change.
-
 | Work | Required reference |
 | --- | --- |
-| Name a new SPEC or change set | Canonical module registry at `<document-repository>/docs/Developing/spec-module-abbreviations.md` |
+| Choose the SPEC maintenance mode | [spec-maintenance-guide.md](references/spec-maintenance-guide.md) |
 | Create or revise `proposal.md` | [proposal-template.md](references/proposal-template.md) |
-| Create or revise `design.md`; design D1 cases | [design-template.md](references/design-template.md) and [test-design-guide.md](references/test-design-guide.md) |
+| Create or revise `design.md`; design formal D1-D5 cases | [design-template.md](references/design-template.md) and [test-design-guide.md](references/test-design-guide.md) |
 | Create or revise `task.md` | [task-template.md](references/task-template.md) |
 | Plan, execute, or close verification | [verification-guide.md](references/verification-guide.md) |
 
-`proposal.md` owns current-change AC definitions, `design.md` owns design rationale and test design, and `task.md` owns the single traceability/evidence table. A delta owns proposed requirement text when delta mode is selected. Preserve established baseline requirements, historical ACs, and approved decisions. Follow each template's required, conditional, and optional sections; remove unused optional sections and placeholders.
-
-This workflow adapts [OpenSpec](https://github.com/Fission-AI/OpenSpec/blob/main/schemas/spec-driven/schema.yaml) to Nexent. It uses singular `task.md`, local document paths, and manual baseline/delta integration; it does not claim OpenSpec CLI compatibility.
+Use `nexent-test-assets` for the concrete feature-catalog, case, automation, manifest, schema, and Excel formats. `proposal.md` owns the current-change acceptance criteria, `design.md` owns design rationale and test strategy, and `task.md` owns the change-level traceability and evidence record.
 
 ## Gated workflow
 
 ### 1. Analyze
 
-Search existing SPECs and choose the document mode before writing. For a new SPEC or change set, resolve its owning level-1 module and use a registered level-2 module when the scope has one stable owner; then choose a 2-to-5-word feature description. Inspect the relevant code, callers, interfaces, persistence, services, UI, tests, configuration, and runtime paths. Cite concrete paths, symbols, APIs, schemas, and configuration names. Do not implement production code during analysis.
+Search existing SPECs and choose the maintenance mode. Inspect the relevant code, callers, interfaces, persistence, services, UI, formal test assets, configuration, and runtime paths. Cite concrete paths, symbols, APIs, schemas, and configuration names. Do not implement production code during analysis.
 
-### 2. Write and review the SPEC
+### 2. Define behavior and formal D1-D5 cases
 
-Create or update `proposal.md` and `design.md`, then `task.md`. Define stable requirement feature IDs and observable ACs with verification layers, evidence, and exact pass conditions. For an undocumented bug, reconstruct the owning feature's main behavior and design while keeping implementation scope limited to the requested fix.
+Create or update `proposal.md`, `design.md`, and `task.md`. Update the product feature catalog and define observable acceptance criteria. Design every applicable D1-D5 case before product implementation. Each case must have a stable Case ID, owning Feature ID, priority, precise preconditions, steps, expected results, forbidden side effects, and the stage-specific fields required by the repository schemas.
 
-In `design.md`, map every in-scope Scenario and relevant unit-level design contract to stable D1 case IDs at the lowest proving layer: `FE-COMP`, `BE-UT`, or `SDK-UT`. Define implementable preconditions, steps, assertions, forbidden side effects, priority, fixtures/mocks, and later verification exclusions. Build the `task.md` traceability table from requirements, ACs, design sections, D1 cases, later verification, and planned evidence.
+Create a requirement change record under `test/changes/requirements/` or a lightweight bug record under `test/changes/bugs/`. Run the formal asset validators and regenerate the Excel view. Do not invent final script paths, selectors, implementation hashes, or passing results during design.
 
-Review the documents, any delta, baseline references, and actual code together. The design gate fails if a Scenario lacks a D1 case, a case lacks implementable assertions, a case crosses its declared boundary, or the matrix is stale. Resolve questions that change scope, behavior, design, tests, or tasks. Production implementation starts only after explicit approval; explicit autonomous authorization may be recorded with a self-review in `task.md`.
+The design gate fails when an in-scope behavior lacks an applicable case or justified exclusion, a case lacks executable assertions, stage boundaries are violated, affected Feature/Case declarations are stale, or schema and traceability validation fail. Resolve material behavior conflicts before implementation. No separate manual test-case approval is required by this workflow.
 
-### 3. Write D1 tests first
+### 3. Implement the product behavior
 
-Implement the designed tests before the corresponding production behavior and bind each test to its case ID. Use fixed fixtures and mocks only for isolation or controlled faults. For a bug, preserve a focused reproduction that fails before the fix when feasible. Run the smallest relevant group and confirm the expected failure before production edits when a meaningful red step is possible; otherwise record the concrete reason in `task.md`.
+Implement the minimum change needed to satisfy the defined behavior, following existing architecture and contracts. If implementation reveals that a requirement, product rule, Scenario, or test contract is wrong, update and validate the formal design assets before continuing. Do not silently weaken a case to fit the implementation.
 
-Missing, unimplemented, skipped, or expected-failure cases do not pass. Keep product, test, and environment failures distinguishable.
+### 4. Implement fixed tests and the manifest
 
-### 4. Implement and pass D1
+After product implementation, implement the affected formal D1-D5 scripts under `test/automation/d1` through `test/automation/d5`. Bind each automated script or test item to its Case ID and incrementally update only the affected entries in `test/manifests/d1-d5.yaml`. Then run full manifest and traceability validation.
 
-Implement the minimum approved production change needed to satisfy the cases, following existing architecture and contracts. Each feature task names its AC and case IDs and completes only after all associated assertions, including forbidden side effects, pass.
+For a confirmed bug, a focused failing reproduction may be implemented before the product fix when that is the clearest way to preserve the regression. Existing formal cases should be strengthened instead of duplicated when they already own the behavior.
 
-Run the smallest group while developing, then the complete affected D1 group. Do not weaken assertions to pass. When implementation changes a requirement, Scenario, contract, boundary, or design, update and re-review the documents and matrix before continuing.
+Legacy UT maintenance remains separate and uses `nexent-python-tests` only when the change breaks or intentionally updates that suite.
 
-### 5. Verify changed behavior
+### 5. Verify affected behavior
 
-After required D1 cases pass, execute every later verification layer triggered by the change. Use a real browser for frontend interaction, a running service and real requests for HTTP contracts, stable-interface tests for internal behavior, and actual Nexent paths plus configured services and Langfuse evidence for model, embedding, or Agent runtime behavior.
+Run the affected formal D1-D5 cases selected from the change record. Use fixed Playwright scripts for D4. Keep Mock and Real Smoke results distinct when both profiles apply. Missing, unimplemented, skipped, or expected-failure required cases do not pass. Keep product, test, environment, and external-provider failures distinguishable.
 
-Source review, mocks, builds, and D1 results do not replace required functional verification. Missing required credentials, infrastructure, or evidence makes the affected AC `BLOCKED`. Follow the verification guide for secret handling, proof details, and statuses.
+Record sanitized commands, results, evidence paths, and unresolved blockers in `task.md`. Do not claim API, browser, model, Agent, security, reliability, performance, or deployment acceptance from a lower layer.
 
 ### 6. Close out
 
-Update `task.md` with actual code paths, case results, commands/scenarios, artifacts, trace references, and approved deviations. Use `PASS` only after all required proofs pass; use `PENDING`, `FAIL`, `BLOCKED`, and justified layer-level `N/A` as defined by the verification guide.
-
-Confirm the SPEC, delta, design, tasks, tests, and implementation agree. Integrate approved and verified deltas into the baseline, preserve delta history, and resolve concurrent baseline changes. Report changed files, AC results, executed checks, remaining risks, and unverified items. Completion requires every current required AC to be `PASS`.
+Run the unified formal-asset validator, deterministic Excel check, affected tests, and relevant product checks. Confirm SPEC, feature catalog, cases, change record, scripts, manifest, implementation, and evidence agree. Report changed files, Case results, remaining risks, and unverified items. Formal completion requires every current required acceptance criterion to pass.
 
 ## Stop conditions
 
-Pause the affected work when approval is missing, a material requirement conflict remains unresolved, required access or evidence is unavailable, verification would mutate a system outside the authorized scope, or an AC cannot be proved with the available surface. Explain the affected ACs and missing input, and continue safe independent work when the blocker is local.
+Pause the affected work when a material behavior conflict remains unresolved, required access or evidence is unavailable, verification would mutate a system outside the authorized scope, or an acceptance criterion cannot be proved with the available surface. Continue safe independent work when the blocker is local.