cclaw-cli 0.5.14 → 0.5.15

package/dist/content/contracts.js

@@ -11,6 +11,12 @@ export function commandContract(stage) {
     const gateIds = schema.requiredGates
         .map((g) => `\`${g.id}\``)
         .join(", ");
+    const writes = schema.crossStageTrace.writesTo;
+    const writesLine = writes.map((w) => `\`${w}\``).join(", ");
+    const primaryArtifact = `.cclaw/artifacts/${schema.artifactFile}`;
+    const writeStepPaths = writes.length > 1
+        ? writes.map((w) => `\`${w}\``).join(" and ")
+        : `\`${primaryArtifact}\``;
     return `# /cc-${stage}
 
 Load and follow **${skillPath}** — it contains the full checklist, examples, interaction protocol, and verification discipline.
@@ -20,7 +26,7 @@ ${schema.hardGate}
 
 ## In / Out
 - **Reads:** ${readsLine}
-- **Writes:** \`.cclaw/artifacts/${schema.artifactFile}\`
+- **Writes:** ${writesLine}
 - **Next:** \`/cc-next\` (updates flow-state and loads the next stage)
 
 ## Context Hydration (mandatory before stage work)
@@ -29,7 +35,7 @@ ${schema.hardGate}
 3. Load required upstream artifacts for this stage:
 ${hydrationLines}
 4. Load \`.cclaw/knowledge.md\` and apply relevant entries.
-5. Write stage output to \`.cclaw/artifacts/${schema.artifactFile}\`.
+5. Write stage output to ${writeStepPaths}.
 6. Do NOT copy artifacts into \`.cclaw/runs/\`; archival is handled only by \`cclaw archive\`.
 
 ## Gates

package/dist/content/examples.js

@@ -398,33 +398,39 @@ Execution rule: complete and verify each wave before starting the next wave.
 ### Final Verdict
 
 - BLOCKED`,
-    ship: `### Preflight checklist (sample)
+    ship: `### Preflight Results
 
-- tests ✅ (\`pnpm test\` green on main)
-- build ✅ (\`pnpm build\` succeeds)
-- lint ✅ (\`pnpm lint\` clean)
-- type-check ✅ (\`pnpm typecheck\` clean)
+- Review verdict: APPROVED_WITH_CONCERNS (R-1 resolved, R-2 accepted as known debt)
+- Build: pass (\`pnpm build\` succeeds)
+- Tests: pass (\`pnpm vitest run && pnpm playwright test\` — 47 passed, 0 failed)
+- Lint: pass (\`pnpm lint\` clean)
+- Type-check: pass (\`pnpm typecheck\` clean)
+- Working tree clean: yes (\`git status\` shows no uncommitted changes)
 
-### Release notes (sample)
+### Release Notes
 
-- **Added:** In-app notification feed with SSE updates and REST fallback snapshotting.
-- **Changed:** Notification payloads now include a stable dedupe key for idempotent rendering.
+- **Added:** In-app notification feed with SSE updates and REST fallback snapshotting (AC-1, AC-3).
+- **Changed:** Notification payloads now include a stable dedupe key for idempotent rendering (AC-2).
 - **Fixed:** Panel no longer drops the newest item when reconnecting after sleep/resume.
+- **Breaking changes:** None.
 
-### Rollback plan (sample)
+### Rollback Plan
 
-1. Revert release tag \`v1.14.0\` to \`v1.13.2\` and redeploy the previous container image from the registry.
-2. If database migrations shipped, run the documented down migration \`2026_04_12_notifications_cursor_down.sql\` before serving traffic again.
+- Trigger conditions: error rate on \`/notifications/stream\` exceeds 5% for >5 minutes, or p95 publish-to-visible lag exceeds 10s.
+- Rollback steps: \`git revert <merge-sha> && git push origin main\` then redeploy; if DB migrations shipped, run \`2026_04_12_notifications_cursor_down.sql\` before traffic.
+- Verification steps: confirm error rate returns to pre-release baseline within 10 minutes; smoke-test feed panel manually.
 
-### Post-release monitoring (sample)
+### Monitoring
 
-- Watch error rate on \`/notifications/stream\` and snapshot endpoint separately for 24 hours.
-- Track p95 “publish → visible” lag via existing metrics dashboard; alert if SLO regresses.
+- Metrics/logs to watch: error rate on \`/notifications/stream\` and snapshot endpoint for 24h; p95 publish-to-visible lag via metrics dashboard.
+- Risk note (if no monitoring): N/A — monitoring is in place.
 
-### Communications (sample)
+### Finalization
 
-- Post a short internal changelog entry linking to release notes and rollback doc location.
-- If user-visible behavior changes, prepare a one-paragraph support macro explaining the new feed + fallback behavior.`,
+- Selected enum: FINALIZE_OPEN_PR
+- Selected label: B
+- Execution result: PR #42 created via \`gh pr create\`; CI passed; squash-merged to main.
+- PR URL: https://github.com/example/repo/pull/42`,
 };
 export function stageExamples(stage) {
     const examples = STAGE_EXAMPLES[stage];

package/dist/content/stage-schema.js

@@ -1350,7 +1350,8 @@ const SHIP = {
         { id: "ship_release_notes_written", description: "Release notes are complete and accurate." },
         { id: "ship_rollback_plan_ready", description: "Rollback trigger, steps, and verification are documented." },
         { id: "ship_finalization_mode_selected", description: "Exactly one finalization action is selected." },
-        { id: "ship_finalization_executed", description: "Selected finalization action was executed and verified." }
+        { id: "ship_finalization_executed", description: "Selected finalization action was executed and verified." },
+        { id: "ship_post_merge_tests", description: "Full test suite re-run on the merged result (not just the branch). Post-merge failures caught before release." }
     ],
     requiredEvidence: [
         "Artifact written to `.cclaw/artifacts/08-ship.md`.",
@@ -1383,7 +1384,10 @@ const SHIP = {
     rationalizations: [
         { claim: "Rollback details can be written after release.", reality: "Rollback is part of release readiness, not post-release cleanup." },
         { claim: "Finalization choice is obvious from context.", reality: "Explicit branch action prevents accidental release state." },
-        { claim: "Urgent fixes can skip preflight.", reality: "Urgency increases risk; preflight discipline matters more, not less." }
+        { claim: "Urgent fixes can skip preflight.", reality: "Urgency increases risk; preflight discipline matters more, not less." },
+        { claim: "Monitoring can be set up after deploy.", reality: "If you cannot observe the release, you cannot detect failure. Monitoring is a ship prerequisite, not a follow-up task." },
+        { claim: "A small merge does not need post-merge testing.", reality: "Small merges on diverged bases cause silent conflicts. Post-merge suite runs catch what branch-only CI misses." },
+        { claim: "Release notes are internal documentation, not a ship gate.", reality: "Release notes are the rollback decision input. Without them, the team cannot assess what changed or why a rollback is needed." }
     ],
     redFlags: [
         "No rollback trigger/steps",
@@ -1408,7 +1412,8 @@ const SHIP = {
         { name: "Rollback-First Thinking", description: "Before shipping, answer: what tells me this is broken? How do I undo it? How do I verify the undo worked? If you cannot answer all three, you are not ready." },
         { name: "Explicit Over Implicit Finalization", description: "Merge, PR, keep, discard — each has different consequences. Pick one. Say it out loud. Write it down. Never let finalization be 'whatever the default is.'" },
         { name: "Post-Merge Paranoia", description: "The merge itself can introduce failures even when both branches pass independently. Always run the full suite AFTER merge, not just before." },
-        { name: "Observability Before Ship", description: "If you cannot monitor the change in production, you cannot know if it is broken. Monitoring/logging is a ship prerequisite, not a follow-up." }
+        { name: "Observability Before Ship", description: "If you cannot monitor the change in production, you cannot know if it is broken. Monitoring/logging is a ship prerequisite, not a follow-up." },
+        { name: "Release Blast Radius", description: "Before shipping, map the blast radius: how many users are affected if this breaks? Is it one endpoint or the entire app? Scale rollback urgency and monitoring to the blast radius, not the diff size. A 3-line auth change can have infinite blast radius." }
     ],
     reviewSections: [
         {
@@ -1435,17 +1440,22 @@ const SHIP = {
     ],
     completionStatus: ["SHIPPED", "SHIPPED_WITH_EXCEPTIONS", "BLOCKED"],
     crossStageTrace: {
-        readsFrom: [".cclaw/artifacts/07-review.md", ".cclaw/artifacts/06-tdd.md"],
+        readsFrom: [".cclaw/artifacts/07-review.md", ".cclaw/artifacts/06-tdd.md", ".cclaw/artifacts/05-plan.md", ".cclaw/artifacts/04-spec.md"],
         writesTo: [".cclaw/artifacts/08-ship.md"],
-        traceabilityRule: "Ship artifact must reference review verdict and resolution status. Rollback plan must reference specific changes that could fail."
+        traceabilityRule: "Ship artifact must reference review verdict and resolution status. Release notes must reference spec criteria. Rollback plan must reference specific changes that could fail."
     },
     artifactValidation: [
         { section: "Preflight Results", required: true, validationRule: "Build, test, lint, type-check results captured with fresh output. Exceptions documented if any." },
         { section: "Release Notes", required: true, validationRule: "What changed, why, impact. References spec criteria. Breaking changes flagged." },
         { section: "Rollback Plan", required: true, validationRule: "Trigger conditions, rollback steps (exact commands), verification steps." },
         { section: "Monitoring", required: false, validationRule: "If applicable: what metrics/logs to watch post-deploy. Risk note if no monitoring." },
-        { section: "Finalization", required: true, validationRule: "Exactly one finalization enum token selected. Execution result documented. Worktree cleaned if applicable." }
-    ]
+        { section: "Finalization", required: true, validationRule: "Exactly one finalization enum token selected. Execution result documented. Worktree cleaned if applicable." },
+        { section: "Completion Status", required: false, validationRule: "If present: exactly one of SHIPPED, SHIPPED_WITH_EXCEPTIONS, BLOCKED. Exceptions documented when applicable." }
+    ],
+    namedAntiPattern: {
+        title: "Green CI Means Safe to Merge",
+        description: "CI passing on a feature branch does not prove the merged result is safe. Post-merge test failures are common when the base branch has diverged. Re-run the full suite on the merge result, not just the branch. A green branch badge is a necessary condition, not a sufficient one."
+    }
 };
 // ---------------------------------------------------------------------------
 // Stage map and accessors

package/dist/content/templates.js

@@ -422,6 +422,10 @@ Execution rule: complete and verify each wave before starting the next wave.
 - Selected label (A/B/C/D):
 - Execution result:
 - PR URL / merge commit / kept branch / discard confirmation:
+
+## Completion Status
+- SHIPPED | SHIPPED_WITH_EXCEPTIONS | BLOCKED
+- Exceptions (if any):
 `
 };
 export const RULEBOOK_MARKDOWN = `# Cclaw Rulebook

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cclaw-cli",
-  "version": "0.5.14",
+  "version": "0.5.15",
   "description": "Installer-first flow toolkit for coding agents",
   "type": "module",
   "bin": {