@metasession.co/devaudit-sdlc 0.3.18 → 0.3.19

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@metasession.co/devaudit-sdlc",
-  "version": "0.3.18",
+  "version": "0.3.19",
   "description": "DevAudit SDLC CLI Engine — cross-agent terminal-driven SDLC orchestrator.",
   "bin": {
     "devaudit-sdlc": "./src/bin/devaudit-sdlc.js"

package/src/blueprints/3-compile-evidence.raw.md

@@ -82,7 +82,7 @@ A release is classified by version shape and release mode. **Most of this doc wa
 
 ### Housekeeping outcomes
 
-Normal housekeeping skips the per-requirement evidence and approval path. Run the relevant gates, obtain terminal-green PR review, and merge to `develop`; the bare-date portal row is integration history. When a tracked release later absorbs the work, its bundled-change manifest preserves the source title, evidence ownership, stage, and cycles.
+Normal housekeeping skips the per-requirement evidence and approval path. Run the relevant gates, obtain terminal-green PR review, and merge to `develop`; the bare-date portal row is integration history. When a tracked release later absorbs the work, its bundled-change manifest preserves the source title, evidence ownership, stage, and executions.
 
 Use standalone housekeeping only when the change cannot reasonably wait for that tracked release. Follow `docs/release-playbooks/housekeeping-release.md`: add the validated `STANDALONE-HOUSEKEEPING-vYYYY.MM.DD.json` declaration, document why promotion is necessary, pass the required checks, and verify production. There is no automatic release-ticket or security-summary stub PR for either housekeeping outcome.
 
@@ -173,27 +173,27 @@ Rules:
 - `environment_gap` and `precondition_gap` skips must be resolved before listing — if they appear here, the gate is not truly `SKIPPED` with operator approval.
 - A skipped test never proves an acceptance criterion.
 
-## Test Cycles
+## Test Executions
 
-Prefer the first-class release-journey / cycle API when the portal exposes it. Generate the table from the API response rather than inferring cycles from uploaded files:
+Prefer the first-class release-journey / execution API when the portal exposes it. Generate the table from the API response rather than inferring executions from uploaded files:
 
 ```bash
 # Example:
 curl -s -H "Authorization: Bearer ${DEVAUDIT_API_KEY}" \
   "${DEVAUDIT_BASE_URL%/}/api/projects/<slug>/releases/REQ-XXX/journey" \
   > /tmp/release-journey.json
-bash scripts/render-test-cycles.sh /tmp/release-journey.json
+bash scripts/render-test-executions.sh /tmp/release-journey.json
 ```
 
-The helper renders a first-class table when `.cycles[]` is present, and falls back to legacy `testCycleId` grouping when the portal has not yet rolled out cycle records.
+The helper renders a first-class table when `.testExecutions[]` is present. It must not infer executions from legacy artifact grouping.
 
-| Source Release | SDLC Stage | Cycle | Kind | Outcome | Workflow / Run | Related Evidence | Incident / Remediation | Date |
+| Source Release | SDLC Stage | Execution | Kind | Outcome | Workflow / Run | Related Evidence | Incident / Remediation | Date |
 | --- | --- | --- | --- | --- | --- | --- | --- | --- |
 | REQ-XXX | 2 implement_test | #1 | quality_gate | passed | [Quality Gates](https://github.com/example/repo/actions/runs/123) (run 123, attempt 1) | quality-gates.json | None | 2026-07-16 11:03:00 |
 | REQ-XXX | 2 implement_test | #2 | e2e | passed | [E2E Regression](https://github.com/example/repo/actions/runs/124) (run 124, attempt 2) | e2e-results.json, screenshots.zip | Incident #501 fixed in PR #507 | 2026-07-16 11:19:00 |
 | REQ-089 | 4 uat_review | #1 | uat | passed | [UAT Review](https://devaudit.example/releases/REQ-089) | uat-checklist.md | None | 2026-07-16 12:02:00 |
 
-**Final assessment:** [First-class cycle records show all stage cycles passed / N cycles failed — see incidents]
+**Final assessment:** [First-class test execution records show all stage executions passed / N executions failed — see incidents]
 
 ## Bundled Release Context
 
@@ -338,12 +338,12 @@ status: "nil"
 
 ## Attestation
 
-No incidents or defects were discovered during the test cycle for release `<version>`.
+No incidents or defects were discovered during the test execution for release `<version>`.
 
 ## Scope
 
 - **Release:** <version>
-- **Test cycle:** <description>
+- **Test execution:** <description>
 - **Test cases executed:** <count>
 - **Test cases passed:** <count>
 - **Test cases failed:** 0
@@ -352,7 +352,7 @@ No incidents or defects were discovered during the test cycle for release `<vers
 
 ## Framework attribution
 
-- [x] `ISO29119.3.5.4` (Test incident report — nil report for this release cycle)
+- [x] `ISO29119.3.5.4` (Test incident report — nil report for this release execution)
 
 ## Sign-off
 

package/src/blueprints/4-submit-for-review.raw.md

@@ -179,7 +179,7 @@ CI runs automatically on this PR. The following gates must pass before merge:
 - [ ] Implementation plan present and matches implementation (MEDIUM/HIGH risk)
 - [ ] Release ticket created
 - [ ] Test evidence saved
-- [ ] Test execution summary includes Test Cycles section (all CI runs for this release listed)
+- [ ] Test execution summary includes Test Executions section (all CI runs for this release listed)
 - [ ] Security evidence saved
 - [ ] AI use documented
 

package/src/blueprints/5-deploy-main.raw.md

@@ -151,7 +151,7 @@ The backend stores both with reviewer identity, SHA, and timestamp. This satisfi
 
 1. Wait for `post-deploy-prod.yml` to complete successfully **and** for its host-deployment check to confirm terminal success for the merged SHA.
 2. Open the release in DevAudit: `https://[DEVAUDIT_BASE_URL]/projects/[PROJECT_SLUG]/releases/[releaseId]`.
-3. Review the production deployment and smoke cycle records, their evidence, and any post-deploy actions logged in the release ticket. Do not approve while either cycle or the host deployment remains queued/in progress.
+3. Review the production deployment and smoke test execution records, their evidence, and any post-deploy actions logged in the release ticket. Do not approve while either execution or the host deployment remains queued/in progress.
 4. Click **Approve Production** — status transitions to `prod_approved`.
 5. Click **Mark as Released** — status transitions to `released`. This dispatches the automated close-out flow.
 

package/src/blueprints/implementing-an-sdlc-issue.raw.md

@@ -67,7 +67,7 @@ The [`sdlc-implementer`](#skills-inventory) skill is the **default way to implem
 > Implement issue #N under the SDLC.
 ```
 
-It **triages first** (Phase 0): it reads the issue + labels, classifies the change-type against the [change-workflows](https://github.com/metasession-dev/DevAudit-Installer/blob/main/docs/change-workflows.md) taxonomy, announces a **Workflow Decision** (which path, which gates, which approvals, what's skipped), and routes — only a tracked change continues into the full cycle; housekeeping / trivial / doc-only is announced and handed off to its lighter path. So pointing the skill at an issue no longer defaults to maximum ceremony — it decides the path at pickup.
+It **triages first** (Phase 0): it reads the issue + labels, classifies the change-type against the [change-workflows](https://github.com/metasession-dev/DevAudit-Installer/blob/main/docs/change-workflows.md) taxonomy, announces a **Workflow Decision** (which path, which gates, which approvals, what's skipped), and routes — only a tracked change continues into the full execution; housekeeping / trivial / doc-only is announced and handed off to its lighter path. So pointing the skill at an issue no longer defaults to maximum ceremony — it decides the path at pickup.
 
 For a tracked change it then runs Phases 1–4 unattended (with a plan-approval pause for HIGH/CRITICAL risk, or always-on via `--require-plan-approval`): classify risk, assign the next `REQ-XXX`, write the implementation plan, update `RTM.md`, implement, delegate all end-to-end / visual test work to [`e2e-test-engineer`](#skills-inventory), run the gates, compile evidence, open the PR, and submit for UAT review on the portal. It then **halts** at the UAT gate. After a reviewer approves on the portal:
 
@@ -77,9 +77,9 @@ For a tracked change it then runs Phases 1–4 unattended (with a plan-approval
 
 It runs Phase 5: merge, monitor post-deploy, confirm production smoke evidence, advance the release. If changes are requested at UAT instead of approval, it addresses them and re-submits for UAT re-review. It **refuses** issues that decompose into multiple requirements (split them first).
 
-**Where it routes (the Phase-0 decision):** the skill now makes this call at pickup rather than you discovering mid-PR that you over- (or under-) ceremonied. It still **drives each path to completion** — these are the paths it takes *instead of* the full tracked cycle, not points where it abandons you:
+**Where it routes (the Phase-0 decision):** the skill now makes this call at pickup rather than you discovering mid-PR that you over- (or under-) ceremonied. It still **drives each path to completion** — these are the paths it takes *instead of* the full tracked execution, not points where it abandons you:
 
-- **Trivial / housekeeping changes** → the skill drives the lightweight escape hatch (above) to merge: branch → all gates locally → `chore:`/`docs:`/`ci:` PR → review → merge. No requirement, no tracked cycle, but it guides every step. Docs, formatting, dependency bumps, CI tweaks (`docs:` / `chore:` / `ci:` …) don't need a requirement. (Note: `feat` / `fix` / `refactor` / `perf` commits **do** require a `[REQ-XXX]` / `Ref: REQ-XXX` and are rejected by commitlint + `validate-commits.sh` without one.)
+- **Trivial / housekeeping changes** → the skill drives the lightweight escape hatch (above) to merge: branch → all gates locally → `chore:`/`docs:`/`ci:` PR → review → merge. No requirement, no tracked execution, but it guides every step. Docs, formatting, dependency bumps, CI tweaks (`docs:` / `chore:` / `ci:` …) don't need a requirement. (Note: `feat` / `fix` / `refactor` / `perf` commits **do** require a `[REQ-XXX]` / `Ref: REQ-XXX` and are rejected by commitlint + `validate-commits.sh` without one.)
 - **Compliance-doc-only** → the skill drives a docs push against an **existing** `REQ-XXX` through to merge; no new requirement, no quality gates.
 - **Stage-1 planning in isolation, or e2e test work alone** → run the manual walkthrough / invoke `e2e-test-engineer` directly.
 - **Cross-issue refactors** spanning multiple `REQ-XXX` scopes → out of the one-issue contract; the skill refuses and asks you to split.