@metasession.co/devaudit-sdlc 0.3.15 → 0.3.16
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -70,37 +70,21 @@ Both `ci.yml` and `compliance-evidence.yml` call the same helper, so a feature s
|
|
|
70
70
|
|
|
71
71
|
If you need a separate release container for a sub-piece of work — e.g. carving REQ-038 out of an in-flight feature — give it its own REQ-ID and tag the commits accordingly.
|
|
72
72
|
|
|
73
|
-
##
|
|
73
|
+
## Release modes
|
|
74
74
|
|
|
75
|
-
A release is classified by
|
|
75
|
+
A release is classified by version shape and release mode. **Most of this doc walks the tracked path** (a REQ-XXX-tagged release for a single requirement). For develop pushes without a REQ tag — typically `docs:`, `chore:`, `ci:`, `build:`, `test:`, `compliance:`, `revert:` — the version deriver falls back to a bare date.
|
|
76
76
|
|
|
77
|
-
|
|
|
77
|
+
| Mode | Version pattern | Triggered by | Outcome |
|
|
78
78
|
| --- | --- | --- | --- |
|
|
79
79
|
| **Tracked** | `REQ-037`, `REQ-046-FIX`, etc. | A `feat`/`fix`/`refactor`/`perf` commit (REQ tag required by commitlint) | Yes — full Steps 1-9 |
|
|
80
|
-
| **
|
|
80
|
+
| **Integration housekeeping** | `v2026.06.04` (bare date, optionally `.N`) | A normal REQ-exempt change | Terminal-green reviewed integration history; no tracked approval ceremony |
|
|
81
|
+
| **Standalone housekeeping** | `v2026.06.04` (bare date, optionally `.N`) | An explicitly declared exception | Distinct release only after its validated declaration, reason, and production verification |
|
|
81
82
|
|
|
82
|
-
### Housekeeping
|
|
83
|
+
### Housekeeping outcomes
|
|
83
84
|
|
|
84
|
-
|
|
85
|
+
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.
|
|
85
86
|
|
|
86
|
-
|
|
87
|
-
| --- | --- | --- | --- |
|
|
88
|
-
| Release ticket | `compliance/pending-releases/RELEASE-TICKET-REQ-XXX.md` (Step 8) | `compliance/pending-releases/RELEASE-TICKET-<version>.md` (e.g. `RELEASE-TICKET-v2026.06.04.md`) | **Yes** — `generate-housekeeping-release-ticket.sh` runs after `derive-release-version.sh` and emits a stub the operator reviews + signs off |
|
|
89
|
-
| Security summary | `compliance/evidence/REQ-XXX/security-summary.md` (Step 4) | `compliance/security-summary-<version>.md` at the compliance root (release-scoped, not REQ-scoped) | **Yes** — `generate-security-summary.sh` scrapes the SAST + dep-audit gate JSON and emits a stub with an operator sign-off block |
|
|
90
|
-
|
|
91
|
-
**Filename conventions are enforced.** Release tickets must match `RELEASE-TICKET-REQ-XXX.md` or `RELEASE-TICKET-vYYYY.MM.DD.md` exactly. Security summaries must be named `security-summary.md` exactly. The CI upload pipeline (`compliance-evidence.yml`) routes per-REQ artifacts by basename to specific `evidence_type` values — unrecognized filenames are skipped with a warning (DevAudit-Installer#205). The `validate-compliance-artifacts.sh` PR-time check also warns on unrecognized filenames in `compliance/evidence/REQ-XXX/`. The version-suffixed conventions above are recommended for **searchability + audit trail** when a project has many housekeeping releases stacked up — they keep the artefacts distinct per release without needing folder scoping.
|
|
92
|
-
|
|
93
|
-
**What housekeeping operators do, end to end:**
|
|
94
|
-
|
|
95
|
-
1. Push the `docs:` / `chore:` / `ci:` commits to develop. CI runs the four gates as usual.
|
|
96
|
-
2. CI's `compliance-evidence.yml` workflow auto-opens a PR (`chore/housekeeping-release-<version>`) containing the two stubs.
|
|
97
|
-
3. Review the stubs — confirm the commit-summary list in the release ticket is sensible, confirm the SAST + dep-audit summary reads correctly, fill in the operator sign-off block on each.
|
|
98
|
-
4. Merge that PR. The next CI run picks up the artefacts and the portal's release-completeness checklist flips both items to ✓.
|
|
99
|
-
5. Submit for UAT review on the portal. The approval flow is identical to the tracked path — same four-eyes rules (per project risk tier), same `draft → uat_review → uat_approved → prod_review → prod_approved → released` state machine.
|
|
100
|
-
|
|
101
|
-
**No auto-approval.** Housekeeping releases still require operator action to advance through the gates. The CI-generated stubs replace the operator's authoring effort, not the operator's review.
|
|
102
|
-
|
|
103
|
-
> **Versions of the framework before 2026-06 produced housekeeping stubs by hand.** Older release records may have `security-summary.md` under a REQ-XXX-shaped folder or no release ticket at all — leave those in DRAFT for the audit trail; backfilling isn't required.
|
|
87
|
+
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.
|
|
104
88
|
|
|
105
89
|
## Steps
|
|
106
90
|
|
|
@@ -55,7 +55,7 @@ A worked end-to-end example for a zero-risk change (a typo, a dependency bump, a
|
|
|
55
55
|
3. **Commit with a housekeeping type.** `docs:` / `chore:` / `ci:` / `build:` / `test:` / `revert:` are **exempt** from the `[REQ-XXX]` rule — e.g. `git commit -m "docs: fix typo in README"`. A `feat` / `fix` / `refactor` / `perf` subject without a `[REQ-XXX]` or `Ref: REQ-XXX` is **rejected** by commitlint and `validate-commits.sh` — if that fires, you picked the wrong type and the change isn't trivial.
|
|
56
56
|
4. **Run the gates locally — not optional.** `npx tsc --noEmit`, lint, and the test suite must pass before you push. Trivial ≠ unverified.
|
|
57
57
|
5. **Push and open a PR.** CI runs the same quality gates. `compliance-validation.yml` finds no `REQ-XXX` and **skips** artifact validation; no release ticket, no RTM row, no evidence pack is required.
|
|
58
|
-
6. **Merge
|
|
58
|
+
6. **Merge only after terminal-green CI** and reviewer approval. A housekeeping push may create a bare-date portal row, but it is integration history, not a UAT/production approval release. It needs no release ticket, security-summary stub, per-REQ evidence pack, or portal sign-off. The next tracked REQ records absorbed work through bundled-change lineage. Use standalone housekeeping only through the explicit declaration and production-verification path in the release playbook.
|
|
59
59
|
|
|
60
60
|
If at any step it stops feeling trivial — it changes behaviour, touches auth/payments/data, or an auditor would ask about it — switch to a tracked change and run `sdlc-implementer`. When unsure, it's not trivial.
|
|
61
61
|
|