@metasession.co/devaudit-cli 0.3.11 → 0.3.13

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@metasession.co/devaudit-cli",
-  "version": "0.3.11",
+  "version": "0.3.13",
   "description": "DevAudit CLI — installs, syncs, and operates the Metasession SDLC across consumer projects.",
   "type": "module",
   "bin": {
@@ -33,7 +33,7 @@
   },
   "dependencies": {
     "@clack/prompts": "^0.8.2",
-    "@metasession.co/devaudit-plugin-sdk": "^0.3.11",
+    "@metasession.co/devaudit-plugin-sdk": "^0.3.13",
     "ajv": "^8.20.0",
     "commander": "^12.1.0",
     "consola": "^3.2.3",

package/scripts/upload-evidence.sh

@@ -47,6 +47,14 @@
 #                               portal group evidence by test cycle per
 #                               ISO/IEC/IEEE 29119-3. Optional — older
 #                               portals ignore the field (no error).
+#   --evidence-scope <scope>    Evidence ownership scope: release | stage |
+#                               cycle | approval. Forwarded as
+#                               `evidenceScope`; optional and ignored by
+#                               older portals.
+#   --test-cycle-record-id <id> First-class portal cycle UUID. Requires
+#                               `--evidence-scope cycle`. Forwarded as
+#                               `testCycleRecordId`; preserved alongside
+#                               legacy `--test-cycle` during dual-write.
 #
 # Required environment variables:
 #   DEVAUDIT_BASE_URL  e.g. https://meta-comply-production.up.railway.app
@@ -98,6 +106,10 @@ CHANGE_TYPE=""
 GATE_STATUS=""
 SDLC_STAGE=""
 TEST_CYCLE=""
+EVIDENCE_SCOPE=""
+TEST_CYCLE_RECORD_ID=""
+SENTINEL_CONTENT=""
+COMMIT_TIMESTAMP=""
 # Repeatable `--meta-key key=value` accumulator. Each pair gets merged
 # into the metadata JSON sent to the portal. Used by the screenshot
 # upload loop to pass `origin=feature|regression` from the per-PNG
@@ -125,6 +137,8 @@ while [ "$#" -gt 0 ]; do
     --gate-status) GATE_STATUS="$2"; shift 2 ;;
     --sdlc-stage) SDLC_STAGE="$2"; shift 2 ;;
     --test-cycle) TEST_CYCLE="$2"; shift 2 ;;
+    --evidence-scope) EVIDENCE_SCOPE="$2"; shift 2 ;;
+    --test-cycle-record-id) TEST_CYCLE_RECORD_ID="$2"; shift 2 ;;
     # --meta-key key=value (repeatable). Merged into the metadata JSON
     # before posting. Validates the `key=value` shape; rejects bare
     # keys without `=`.
@@ -152,6 +166,14 @@ if [ -n "$SDLC_STAGE" ] && ! [[ "$SDLC_STAGE" =~ ^[1-5]$ ]]; then
   echo "Error: --sdlc-stage must be an integer 1-5 (got: $SDLC_STAGE)"
   exit 1
 fi
+if [ -n "$EVIDENCE_SCOPE" ] && ! [[ "$EVIDENCE_SCOPE" =~ ^(release|stage|cycle|approval)$ ]]; then
+  echo "Error: --evidence-scope must be one of: release, stage, cycle, approval"
+  exit 1
+fi
+if [ -n "$TEST_CYCLE_RECORD_ID" ] && [ "$EVIDENCE_SCOPE" != "cycle" ]; then
+  echo "Error: --test-cycle-record-id requires --evidence-scope cycle"
+  exit 1
+fi
 
 if [ -z "${DEVAUDIT_BASE_URL:-}" ]; then
   echo "Error: DEVAUDIT_BASE_URL environment variable is required"
@@ -202,6 +224,28 @@ probe_base_url_drift() {
 }
 probe_base_url_drift
 
+is_tracked_change_type() {
+  case "${1:-}" in
+    feat|fix|refactor|perf|compliance|revert) return 0 ;;
+    *) return 1 ;;
+  esac
+}
+
+resolve_sentinel_context() {
+  if ! is_tracked_change_type "$CHANGE_TYPE"; then
+    return 0
+  fi
+  if [ -f ".sdlc-implementer-invoked" ]; then
+    SENTINEL_CONTENT=$(cat .sdlc-implementer-invoked)
+  fi
+  local git_target="HEAD"
+  if [ -n "$GIT_SHA" ]; then
+    git_target="$GIT_SHA"
+  fi
+  COMMIT_TIMESTAMP=$(git show -s --format=%cI "$git_target" 2>/dev/null || true)
+}
+resolve_sentinel_context
+
 # --- Build metadata JSON ---
 # Assemble entries first; only emit `{ ... }` if at least one field is
 # set. Each entry is a `"key":"value"` JSON pair with the value
@@ -213,6 +257,7 @@ META_ENTRIES=()
 [ -n "$GIT_SHA" ] && META_ENTRIES+=("\"gitSha\":\"$(json_escape "$GIT_SHA")\"")
 [ -n "$CI_RUN_ID" ] && META_ENTRIES+=("\"ciRunId\":\"$(json_escape "$CI_RUN_ID")\"")
 [ -n "$BRANCH" ] && META_ENTRIES+=("\"branch\":\"$(json_escape "$BRANCH")\"")
+[ -n "$COMMIT_TIMESTAMP" ] && META_ENTRIES+=("\"commitTimestamp\":\"$(json_escape "$COMMIT_TIMESTAMP")\"")
 for KV in "${META_KEYS[@]}"; do
   KEY="${KV%%=*}"
   VAL="${KV#*=}"
@@ -337,8 +382,13 @@ upload_presigned() {
         \"evidenceCategory\": \"${EVIDENCE_CATEGORY}\",
         \"releaseTitle\": \"${RELEASE_TITLE}\",
         \"releaseSummary\": \"${RELEASE_SUMMARY}\",
+        \"changeType\": \"${CHANGE_TYPE}\",
         \"sdlcStage\": \"${SDLC_STAGE}\",
-        \"testCycleId\": \"${TEST_CYCLE}\"
+        \"testCycleId\": \"${TEST_CYCLE}\",
+        \"evidenceScope\": \"${EVIDENCE_SCOPE}\",
+        \"testCycleRecordId\": \"${TEST_CYCLE_RECORD_ID}\",
+        \"sentinelContent\": $(jq -Rn --arg v "$SENTINEL_CONTENT" '$v'),
+        \"commitTimestamp\": \"${COMMIT_TIMESTAMP}\"
       }") || curl_exit=$?
     curl_exit=${curl_exit:-0}
     if [ "$curl_exit" -eq 0 ] && [ "$http_code" -ge 200 ] && [ "$http_code" -lt 300 ]; then
@@ -503,6 +553,10 @@ for FILE in "${FILES[@]}"; do
   [ -n "$GATE_STATUS" ] && CURL_ARGS+=(-F "gateStatus=${GATE_STATUS}")
   [ -n "$SDLC_STAGE" ] && CURL_ARGS+=(-F "sdlcStage=${SDLC_STAGE}")
   [ -n "$TEST_CYCLE" ] && CURL_ARGS+=(-F "testCycleId=${TEST_CYCLE}")
+  [ -n "$EVIDENCE_SCOPE" ] && CURL_ARGS+=(-F "evidenceScope=${EVIDENCE_SCOPE}")
+  [ -n "$TEST_CYCLE_RECORD_ID" ] && CURL_ARGS+=(-F "testCycleRecordId=${TEST_CYCLE_RECORD_ID}")
+  [ -n "$SENTINEL_CONTENT" ] && CURL_ARGS+=(-F "sentinelContent=${SENTINEL_CONTENT}")
+  [ -n "$COMMIT_TIMESTAMP" ] && CURL_ARGS+=(-F "commitTimestamp=${COMMIT_TIMESTAMP}")
 
   ATTEMPT=1
   BACKOFF=$INITIAL_BACKOFF_SECONDS

package/sdlc/ai-rules/SDLC_RULES.md

@@ -412,6 +412,16 @@ When the user says implementation is done, or when all acceptance criteria from
 
 After gates pass, create `compliance/evidence/REQ-XXX/test-execution-summary.md` documenting gate results, test changes, and coverage against the test plan. Include links to evidence locations in DevAudit.
 
+If `compliance/pending-releases/BUNDLED-CHANGES-REQ-XXX.md` exists, add a `## Bundled Release Context` section to `test-execution-summary.md` with this minimum structure:
+- `**Core tracked release:**`
+- `**Absorbed predecessor releases:**`
+- `**Absorbed non-release work:**`
+- `**Why bundled here:**`
+- `**Evidence impact:**`
+- `**Reviewer impact:**`
+- `**Security / risk impact:**`
+- `**Reference:**`
+
 Tell the user: **"All gates passed. Let me generate the test execution summary."**
 
 ### Step 2: Upload binary/JSON evidence to DevAudit
@@ -457,6 +467,8 @@ Dependency audit: 0 vulnerabilities
 Evidence uploaded to DevAudit project: [PROJECT_SLUG]
 ```
 
+If `BUNDLED-CHANGES-REQ-XXX.md` exists, add the same structured bundled-release fields to `security-summary.md` and to `ai-use-note.md` (when present), and add `## Bundled Changes` or `## Absorbed Predecessor Releases` to the release ticket with the same minimum fields. The GitHub PR body is supporting context, not the primary audit record.
+
 Verify these also exist in git:
 - `compliance/evidence/REQ-XXX/test-scope.md` (from planning)
 - `compliance/evidence/REQ-XXX/implementation-plan.md` (MEDIUM/HIGH risk — from implementation plan step)
@@ -484,9 +496,9 @@ When creating the PR, include:
 - A **"Test Changes"** section listing test files added/modified, what they cover, and what's NOT covered
 - A **"Where to Find Test Results"** section pointing reviewers to: CI status icons on commits, automated E2E comment, DevAudit portal link, and compliance evidence files in the PR
 
-### Step 6: Commit compliance markdown only (do NOT push yet)
+### Step 6: Commit compliance markdown and push immediately
 
-Commit locally but **do not push**. UAT verification runs against the prior deployment. We batch all compliance + UAT commits into a single push after Step 7 to avoid duplicate CI runs.
+Commit the compliance markdown and **push immediately**. The compliance-only push is cheap, and it is the authoritative trigger for the Compliance Evidence Upload workflow. Pushing now surfaces destination/configuration failures before you waste time on later review steps.
 
 ```bash
 # ONLY commit markdown — binary/JSON evidence is in DevAudit
@@ -508,7 +520,15 @@ Co-Authored-By: [AI tool tag]"
 
 **NEVER `git add` JSON, TXT, HTML, PNG, or JPG evidence files. They belong in DevAudit.**
 
-### Step 7: WAIT CHECKPOINT — UAT Verification (if UAT configured)
+### Step 7: Wait for the Compliance Evidence Upload workflow
+
+```bash
+gh run watch --workflow "Compliance Evidence Upload"
+```
+
+If it fails, fix the upload/configuration problem before proceeding. The portal's Test Reports gate stays red until the authoritative `develop` upload lands, even if `test-execution-summary.md` already exists on a feature branch.
+
+### Step 8: WAIT CHECKPOINT — UAT Verification (if UAT configured)
 
 If the project has a UAT environment that auto-deploys from `develop`, verify the change works on UAT before creating a PR.
 
@@ -547,17 +567,17 @@ Co-Authored-By: [AI tool tag]"
 
 **If UAT fails:** Fix on `develop`, re-run local gates, push, and repeat. Do NOT create a PR until UAT is green.
 
-### Step 8: Push all compliance commits
+### Step 9: Push any UAT-result follow-up commit
 
-Push all batched commits (evidence + UAT results) in a single push. This triggers one CI run instead of multiple.
+If Step 8 added a UAT verification note to `security-summary.md`, push that follow-up commit now.
 
 ```bash
 git push origin develop
 ```
 
-Tell the user: **"UAT verification passed. Compliance commits pushed. Next step: create a PR from develop to main."**
+Tell the user: **"UAT verification passed. Compliance evidence is on the portal. Next step: create a PR from develop to main."**
 
-### Step 9: Verify release exists in DevAudit
+### Step 10: Verify release exists in DevAudit
 
 CI auto-creates releases when uploading evidence (using `--create-release-if-missing`). After pushing, verify the release appears in DevAudit:
 

package/sdlc/files/_common/0-project-setup.md

@@ -22,11 +22,11 @@ This guide configures a new project so that the five pipeline workflows can run
 
 ## Fast path (recommended): `devaudit install`
 
-The DevAudit CLI (`@metasession.co/devaudit-cli`) automates almost all of this guide. It writes `sdlc-config.json`, creates the DevAudit project, issues an API key, sets the GitHub secrets and variables, installs the hook framework, configures branch protection, and syncs the framework templates (CI workflows, hooks, scripts) — in roughly 30 seconds.
+The DevAudit CLI (`@metasession.co/devaudit-cli`) automates almost all of this guide. It writes `sdlc-config.json`, creates the DevAudit project, issues an API key, sets the GitHub secrets and variables, installs the hook framework, configures branch protection, and syncs the framework templates (CI workflows, hooks, scripts). The command starts in seconds; the full operator onboarding flow usually takes about 5-10 minutes.
 
 ```bash
 npm install -g @metasession.co/devaudit-cli   # requires Node >= 22
-devaudit auth login                            # paste your PAT (issued at https://devaudit.metasession.co/settings/tokens)
+devaudit auth login                            # paste your PAT (issued at https://devaudit.ai/settings/tokens)
 devaudit install ../path/to/this-project
 ```
 
@@ -108,12 +108,12 @@ cat > compliance/RTM.md << 'EOF'
 ## Part A: Baseline Requirements
 
 | ID | Requirement | Source | Status |
-|---|---|---|---|
+| --- | --- | --- | --- |
 
 ## Part B: Change Request Traceability
 
-| REQ-ID | Issue | Risk | Evidence | Status | Approver | Date |
-|---|---|---|---|---|---|---|
+| REQ-ID | Issue | Risk | Evidence | Status | PR | Reviewer | AI-tool |
+| -------- | ------- | ------ | ---------- | -------- | ----- | ---------- | --------- |
 EOF
 
 # Commit
@@ -122,6 +122,12 @@ git commit -m "compliance: initialize compliance directory structure"
 git push origin develop
 ```
 
+If any RTM or release-evidence table cell needs literal pipe characters, escape
+them as `\|` rather than writing bare `|`. Typical cases are regexes
+(`stop\|unsubscribe\|opt-out`) and enum examples
+(`open\|in_progress\|closed`). Bare pipes inside a markdown table cell are read
+as extra columns and trigger false-positive MD056/MD060 lint errors.
+
 ---
 
 ## Step 4: CI Pipeline Configuration
@@ -131,7 +137,7 @@ This is the **independent verification gate**. Tests run locally during developm
 ### What CI Must Run
 
 | Pipeline | Trigger | Jobs | Purpose |
-|---|---|---|---|
+| --- | --- | --- | --- |
 | CI | Push to `develop` | TypeScript + SAST + dependency audit + E2E + build | Quality gates + independent verification |
 | Deploy | Merge to `main` | Auto-deploy to hosting platform | Production release |
 
@@ -389,7 +395,7 @@ If any step fails, fix the configuration before starting real work.
 ## Setup Checklist
 
 | Step | Status |
-|---|---|
+| --- | --- |
 | Repository created | [ ] |
 | `develop` branch created | [ ] |
 | Production environment configured (auto-deploy from `main`) | [ ] |

package/sdlc/files/_common/Periodic_Security_Review_Schedule.md

@@ -21,7 +21,7 @@ This schedule applies to all Metasession products and client engagements. Projec
 ## Schedule Overview
 
 | Activity | Frequency | Owner | Evidence Location |
-|---|---|---|---|
+| --- | --- | --- | --- |
 | Full codebase SAST review | Quarterly | QA / Security Lead | `compliance/evidence/periodic/sast-quarterly/` |
 | Dependency deep audit | Quarterly | QA / Security Lead | `compliance/evidence/periodic/dependency-audit/` |
 | Access control review | Quarterly | QA / Security Lead | `compliance/evidence/periodic/access-control/` |
@@ -103,7 +103,7 @@ This schedule applies to all Metasession products and client engagements. Projec
 **Remediation SLAs:**
 
 | Severity | Deadline |
-|---|---|
+| --- | --- |
 | Critical | 7 days |
 | High | 30 days |
 | Medium | 90 days |
@@ -133,7 +133,7 @@ RTO and RPO targets are defined per project in their Test Plans.
 ## Unscheduled Triggers
 
 | Event | Triggered Activity |
-|---|---|
+| --- | --- |
 | Security incident or breach | Full SAST + pen test + access control review |
 | Critical CVE in direct dependency | Immediate audit + patch |
 | Significant architecture change | Access control review + SAST |
@@ -146,7 +146,7 @@ RTO and RPO targets are defined per project in their Test Plans.
 ## Compliance Framework Mapping
 
 | Framework | Control | Covered By |
-|---|---|---|
+| --- | --- | --- |
 | SOC 2 (CC7.1) | System monitoring | Quarterly SAST + audit log review |
 | SOC 2 (CC6.1) | Logical access | Quarterly access control review |
 | SOC 2 (CC8.1) | Change management | Per-feature pipeline + quarterly reviews |
@@ -160,7 +160,7 @@ RTO and RPO targets are defined per project in their Test Plans.
 ## Document Control
 
 | Version | Date | Author | Changes |
-|---|---|---|---|
+| --- | --- | --- | --- |
 | 1.0 | March 2026 | Engineering Leadership | Initial schedule |
 | 1.1 | March 2026 | Engineering Leadership | Updated document references for clean boundary split |
 

package/sdlc/files/_common/README_TEMPLATE.md

@@ -9,7 +9,7 @@
 ### Tier 1 — Universal (Metasession-wide)
 
 | Document | Owns |
-|----------|------|
+| ---------- | ------ |
 | **Test Policy** | Why we test, commitments, AI governance, roles, accountability |
 | **Test Strategy** | How we approach testing — methodology, risk classification, security, AI protocol |
 | **Test Architecture** | What we build with — tools, patterns, code standards, CI config |
@@ -18,7 +18,7 @@
 ### Tier 2 — Project-Specific
 
 | Document | Purpose |
-|----------|---------|
+| ---------- | --------- |
 | **Project Setup** | One-time: repository, CI, compliance configuration |
 | **Test Plan** | Environment, test suites, exit criteria, AI config, evidence |
 | **Workflows 0-5** | Operational pipeline procedures |
@@ -43,7 +43,7 @@
 ## Quick Reference
 
 | Scenario | Workflows |
-|----------|-----------|
+| ---------- | ----------- |
 | New project setup | 0 (once) |
 | New feature (tracked) | 1 → 2 → 3 → 4 → (CI + review) → 5 |
 | Bug fix / docs / config | 2 → 4 → (CI + review) → 5 |
@@ -51,7 +51,7 @@
 ## Mandatory Gates
 
 | Gate | Local | CI (PR) | Threshold |
-|------|-------|---------|-----------|
+| ------ | ------- | --------- | ----------- |
 | TypeScript | Yes | Yes | 0 errors |
 | SAST | Yes | Yes | 0 high/critical |
 | Dependencies | Yes | Yes | 0 high/critical |
@@ -61,7 +61,7 @@
 ## Risk Levels
 
 | Level | Extra Requirements |
-|-------|-------------------|
+| ------- | ------------------- |
 | Low | Standard gates |
 | Medium | + access control + audit log testing |
 | High | + pen test consideration + independent review |
@@ -71,7 +71,7 @@ AI in Medium/High categories raises risk one level.
 ## CI/CD
 
 | Trigger | What Runs |
-|---------|-----------|
+| --------- | ----------- |
 | Push to `develop` | TypeScript + build |
 | PR to `main` | TypeScript + SAST + deps + E2E (unauthenticated) |
 | Merge to `main` | Auto-deploy |
@@ -289,7 +289,7 @@ DevAudit is the centralised compliance evidence portal for all Metasession proje
 Evidence artifacts are uploaded to DevAudit instead of being committed to git.
 
 | Before (git-based) | After (DevAudit) |
-|---------------------|---------------------|
+| --------------------- | --------------------- |
 | `cp e2e-results.json compliance/evidence/REQ-XXX/` | CLI script or CI uploads to DevAudit |
 | `git add compliance/evidence/REQ-XXX/` | Binary artifacts excluded via `.gitignore` |
 | Evidence only visible to repo collaborators | Evidence visible to anyone with an access grant |
@@ -428,7 +428,7 @@ For one-off reviews, generate a time-limited share link instead of creating an a
 Add these to your GitHub repository (Settings → Secrets and variables → Actions):
 
 | Setting | Tab | Value | Source |
-|--------|-----|-------|--------|
+| -------- | ----- | ------- | -------- |
 | `DEVAUDIT_BASE_URL` | Variables | The deployed DevAudit URL, e.g. `https://devaudit.metasession.co` | The hosting team |
 | `DEVAUDIT_API_KEY` | Secrets | Project-scoped API key (`mc_…`) with `uploader` role | DevAudit → Project Settings → API Keys → New key |
 

package/sdlc/files/_common/Test_Architecture.md

@@ -54,7 +54,7 @@ These standards apply to all Metasession products, client engagements, and inter
 ### Unit Layer (Foundation)
 
 | Attribute | Standard |
-|---|---|
+| --- | --- |
 | Coverage | Minimum 70% for critical modules |
 | Speed | Suite completes in < 30 seconds |
 | Scope | Individual functions, methods, components in isolation |
@@ -63,7 +63,7 @@ These standards apply to all Metasession products, client engagements, and inter
 ### Integration Layer (Middle)
 
 | Attribute | Standard |
-|---|---|
+| --- | --- |
 | Coverage | Minimum 80% of integration points |
 | Scope | Component interactions, service integrations, API contracts |
 | Data | In-memory databases or MSW for API mocking |
@@ -71,7 +71,7 @@ These standards apply to all Metasession products, client engagements, and inter
 ### E2E Layer (Top)
 
 | Attribute | Standard |
-|---|---|
+| --- | --- |
 | Coverage | 100% of critical user paths |
 | Scope | Complete user journeys from UI to database |
 | Browser support | Chromium, Firefox, WebKit |
@@ -80,7 +80,7 @@ These standards apply to all Metasession products, client engagements, and inter
 ### Additional Layers
 
 | Layer | Standard |
-|---|---|
+| --- | --- |
 | Security | SAST, SCA, DAST (see Section 3) |
 | Performance | Load and stress testing before major releases |
 | Accessibility | WCAG 2.1 AA for public-facing features |
@@ -93,7 +93,7 @@ These standards apply to all Metasession products, client engagements, and inter
 ### Test Frameworks
 
 | Purpose | Tool | Notes |
-|---|---|---|
+| --- | --- | --- |
 | Unit testing (TS/JS) | Jest or Vitest | Project chooses one |
 | Unit testing (Python) | pytest | |
 | Component testing | React Testing Library | |
@@ -105,7 +105,7 @@ These standards apply to all Metasession products, client engagements, and inter
 ### Test Management
 
 | Purpose | Tool |
-|---|---|
+| --- | --- |
 | Test case management | Qase |
 | CI/CD | GitHub Actions |
 | Reporting | Playwright HTML Reporter, JUnit XML |
@@ -113,7 +113,7 @@ These standards apply to all Metasession products, client engagements, and inter
 ### Security Testing
 
 | Purpose | Tool | When |
-|---|---|---|
+| --- | --- | --- |
 | SAST (static analysis) | Semgrep and/or SonarQube | Every commit |
 | SCA (dependency scanning) | Snyk | Every commit |
 | Dependency updates | Dependabot | Continuous |
@@ -123,14 +123,14 @@ These standards apply to all Metasession products, client engagements, and inter
 ### Performance Testing
 
 | Purpose | Tool |
-|---|---|
+| --- | --- |
 | Load testing | Artillery |
 | Web performance | Lighthouse |
 
 ### Development Tooling
 
 | Purpose | Tool |
-|---|---|
+| --- | --- |
 | Git hooks | Husky |
 | Commit linting | commitlint (Conventional Commits) |
 | Code linting | ESLint |
@@ -200,7 +200,7 @@ Products must implement:
 ### Strategy by Test Level
 
 | Test Level | Data Strategy | Rationale |
-|---|---|---|
+| --- | --- | --- |
 | Unit | Mocked data | Fast, predictable |
 | Integration | In-memory DB or MSW | Isolated, controlled |
 | E2E (local) | Test database (Docker) | Real behavior, containerized |
@@ -230,7 +230,7 @@ Products must implement:
 All products implement these stages in order:
 
 | Stage | Purpose | Exit Criteria |
-|---|---|---|
+| --- | --- | --- |
 | 1. Lint | ESLint + Prettier validation | 0 errors |
 | 2. Type Check | Strict compilation | 0 errors |
 | 3. Unit Tests | Component-level testing with coverage | Meets coverage target |
@@ -290,7 +290,7 @@ npm pkg set scripts.prepare="husky"
 ## 8. Artifact Storage
 
 | Artifact | Storage | Retention |
-|---|---|---|
+| --- | --- | --- |
 | Test results (HTML) | GitHub Actions artifacts | 90 days |
 | Screenshots | GitHub Actions artifacts | 90 days |
 | Videos | GitHub Actions artifacts | 90 days |
@@ -315,7 +315,7 @@ npm pkg set scripts.prepare="husky"
 ### Naming Conventions
 
 | File Type | Pattern | Example |
-|---|---|---|
+| --- | --- | --- |
 | Unit tests | `*.test.ts`, `*.test.tsx` | `auth.test.ts` |
 | Integration tests | `*.integration.test.ts` | `api.integration.test.ts` |
 | E2E tests | `*.spec.ts` | `login.spec.ts` |
@@ -410,7 +410,7 @@ module.exports = {
 ## 11. Coverage & Quality Thresholds
 
 | Metric | Target |
-|---|---|
+| --- | --- |
 | Unit test coverage (critical modules) | 70% minimum |
 | Integration point coverage | 80% minimum |
 | Critical user path E2E coverage | 100% |
@@ -448,7 +448,7 @@ Each product creates a product-specific Test Plan that:
 ## Document Control
 
 | Version | Date | Author | Changes |
-|---|---|---|---|
+| --- | --- | --- | --- |
 | 1.0 | January 2026 | QA Team | Initial creation |
 | 2.0 | March 2026 | QA Team | Clean boundary split — removed compliance/governance content (now in Policy), removed methodology content (now in Strategy). Architecture now owns tools, patterns, code standards, CI config only. Added security tooling table. |
 

package/sdlc/files/_common/Test_Plan_TEMPLATE.md

@@ -21,7 +21,7 @@ For tools, patterns, and code standards: Test Architecture.
 ## Project Overview
 
 | Attribute | Value |
-|---|---|
+| --- | --- |
 | Application | [PROJECT NAME — brief description] |
 | Stack | [e.g., TypeScript, Next.js, MongoDB, Socket.IO] |
 | Hosting | [e.g., Railway, Vercel, AWS] (auto-deploy from `main`) |
@@ -48,7 +48,7 @@ Develop-main with develop branch (per Test Strategy branching patterns):
 ### E2E Tests (Playwright)
 
 | Attribute | Value |
-|---|---|
+| --- | --- |
 | Framework | Playwright (per Test Architecture standard) |
 | Test count | [TOTAL] tests across [N] projects |
 | Unauthenticated (CI) | [COUNT] (run in CI on PR to main) |
@@ -59,7 +59,7 @@ Develop-main with develop branch (per Test Strategy branching patterns):
 ### Unit Tests
 
 | Attribute | Value |
-|---|---|
+| --- | --- |
 | Framework | [Jest / Vitest] |
 | Coverage target | 70% for critical modules |
 | Run command | [e.g., npx vitest run] |
@@ -73,7 +73,7 @@ npx tsc --noEmit   # 0 errors required
 ### SAST Scanning
 
 | Attribute | Value |
-|---|---|
+| --- | --- |
 | Tool | Semgrep (per Test Architecture) |
 | Config | auto |
 | Scan scope | [e.g., src/] |
@@ -103,7 +103,7 @@ npm audit --audit-level=high
 ### Exit (Before PR)
 
 | Gate | Local | CI (PR) | Threshold |
-|---|---|---|---|
+| --- | --- | --- | --- |
 | TypeScript | Yes | Yes | 0 errors |
 | SAST (high/critical) | Yes | Yes | 0 findings |
 | Dependencies (high/critical) | Yes | Yes | 0 vulnerabilities |
@@ -114,7 +114,7 @@ npm audit --audit-level=high
 Additional for Medium/High risk (per Test Strategy risk matrix):
 
 | Gate | Threshold |
-|---|---|
+| --- | --- |
 | Access control tests | RBAC endpoints return correct 401/403 |
 | Audit log tests | Auditable actions produce log entries |
 
@@ -125,7 +125,7 @@ Additional for Medium/High risk (per Test Strategy risk matrix):
 ### Pipeline Configuration
 
 | Trigger | What Runs | Independent Evidence |
-|---|---|---|
+| --- | --- | --- |
 | Push to `develop` | TypeScript check + build | Compilation clean |
 | PR to `main` | TypeScript + SAST + dependency audit + E2E (unauthenticated) | All gates independently verified by GitHub |
 | Merge to `main` | Auto-deploy to hosting platform | Deployment triggered |
@@ -159,13 +159,13 @@ Both required. Local proves comprehensive testing. CI proves it independently.
 Per Test Policy AI governance:
 
 | Tool | Permitted Use |
-|---|---|
+| --- | --- |
 | [e.g., Claude (Anthropic) — Opus 4.6, Sonnet 4.6] | [e.g., Code generation, test generation, documentation, review] |
 
 Documentation requirements (per Test Strategy AI methodology):
 
 | Risk | Commit | Evidence | Prompts |
-|---|---|---|---|
+| --- | --- | --- | --- |
 | Low | `Co-Authored-By` tag | Not required | Not required |
 | Medium | Same | Summary in evidence dir | Summary |
 | High | Same | Detailed record | Detailed |
@@ -224,7 +224,7 @@ compliance/
 Every tracked requirement gets a `test-scope.md` created during the PLAN stage **before implementation**. Scope scales with risk:
 
 | Risk | Content |
-|---|---|
+| --- | --- |
 | Low | Standard gates + acceptance criteria. A few lines. |
 | Medium | Above + targeted testing (access control, audit logging, dependency review), validation approach. Half a page. |
 | High | Above + security testing detail, independent review plan, pen test consideration, business validation, AI detail. One page. |
@@ -258,7 +258,7 @@ curl -s [PRODUCTION_URL]/[NONEXISTENT_ENDPOINT]
 ## Disaster Recovery
 
 | Metric | Target |
-|---|---|
+| --- | --- |
 | RTO | [e.g., 4 hours] |
 | RPO | [e.g., 24 hours] |
 
@@ -292,7 +292,7 @@ Annual pen test scope: [PRODUCTION_URL], API endpoints, auth mechanism, [databas
 ## Workflow Files
 
 | # | File | Purpose |
-|---|---|---|
+| --- | --- | --- |
 | 0 | `0-project-setup.md` | One-time: repository, CI, compliance setup |
 | 1 | `1-plan-requirement.md` | Create REQ, classify risk, generate test scope |
 | 2 | `2-implement-and-test.md` | Code, commit, run all local gates |
@@ -305,7 +305,7 @@ Annual pen test scope: [PRODUCTION_URL], API endpoints, auth mechanism, [databas
 ## Document Control
 
 | Version | Date | Author | Changes |
-|---|---|---|---|
+| --- | --- | --- | --- |
 | 1.0 | [DATE] | [AUTHOR] | Initial plan |
 
 **Parent Documents:** Test Policy, Test Strategy, Test Architecture, Periodic Security Review Schedule (in devaudit/sdlc/files/)

package/sdlc/files/_common/Test_Policy.md

@@ -114,7 +114,7 @@ AI-generated code presents risks distinct from human-authored code:
 ### Permitted AI Tools
 
 | Tool | Permitted Use | Restrictions |
-|---|---|---|
+| --- | --- | --- |
 | Claude (Anthropic) | Code generation, test generation, documentation, review assistance | No deployment without human review |
 | GitHub Copilot | Inline code suggestions | Same review requirements as any AI-generated code |
 
@@ -275,7 +275,7 @@ Project Test Plans (per product)
 ## Document Control
 
 | Version | Date | Author | Changes |
-|---|---|---|---|
+| --- | --- | --- | --- |
 | 1.0 | January 2026 | Engineering Leadership | Initial creation |
 | 2.0 | March 2026 | Engineering Leadership | Added AI governance, security commitments |
 | 3.0 | March 2026 | Engineering Leadership | Clean boundary split — removed content now owned by Test Strategy (methodology) and Test Architecture (tooling) |