warp-os 1.1.2 → 1.2.1

package/dist/warp-release-update/SKILL.md

@@ -141,6 +141,8 @@ Shell commands use Unix syntax (Git Bash). Never use CMD (`dir`, `type`, `del`)
 
 ## AskUserQuestion
 
+**Flow: analysis first, then decision tool.** Present your full reasoning, trade-offs, and recommendations as conversational text — the user wants to read your thinking. Then cap it with AskUserQuestion to formalize the decision. **If you're composing a message with multiple options or "which approach?" language, you MUST end it with AskUserQuestion.** Never present options in prose without the tool.
+
 **Contract:**
 1. **Re-ground:** Project name, branch, current task. (1-2 sentences.)
 2. **Simplify:** Plain English a smart 16-year-old could follow.
@@ -162,9 +164,15 @@ Shell commands use Unix syntax (Git Bash). Never use CMD (`dir`, `type`, `del`)
 Format: `"Option name — X/10 🟢"` (or 🟡 or 🔴). In the label, not the description.
 Rate: 🟢 9-10 complete, 🟡 6-8 adequate, 🔴 1-5 shortcuts.
 
+**Pre-call checklist (verify before every AskUserQuestion invocation):**
+- ☐ Completeness scores in every option label
+- ☐ Recommended option listed first
+- ☐ One decision per question (split if multiple)
+- ☐ Analysis/reasoning already presented in message text above
+
 **Formatting:**
 - *Italics* for emphasis, not **bold** (bold for headers only).
-- After each answer: `✔ Decision {N} recorded [quicksave updated]`
+- After each answer: `✔ Decision {N} recorded`
 - Previews under 8 lines. Full mockups go in conversation text before the question.
 
 ---
@@ -323,12 +331,29 @@ npx turbo run test 2>&1 | tail -30
 TEST SUITE STATUS:
   Total tests: [N]
   Passing: [N]
-  Failing: [N] (MUST be 0 to proceed)
+  Failing: [N]
   Skipped: [N] (each must have documented reason in build-log)
   Runtime: [X]s
 ```
 
-**HARD GATE: If any test fails, stop. Do not ship with failing tests. Fix the test or the code, then re-run.**
+If any tests fail, triage before blocking. Not all failures are equal — failures you introduced are blockers, pre-existing failures are decisions.
+
+```bash
+# Identify pre-existing failures by checking the test against the base branch
+git stash && npx turbo run test 2>&1 | tail -30  # run tests on base state
+git stash pop
+```
+
+```
+TEST FAILURE TRIAGE:
+  In-branch failures (introduced by this diff): [N] — MUST fix before ship
+  Pre-existing failures (existed before this work): [N] — Handle each:
+    - Fix now, OR
+    - Add to TODOS.md with rationale, OR
+    - Document as known issue in PR body
+```
+
+**HARD GATE: In-branch failures (failures introduced by your diff) MUST be fixed before shipping. Pre-existing failures must be handled — fix, defer to TODOS.md with rationale, or document as known issue in the PR body — but each must have an explicit decision, not silent acceptance.**
 
 ### 1C. Security Recency Check
 
@@ -368,6 +393,69 @@ QA READINESS:
 
 **HARD GATE: If QA readiness is NO-GO, stop. Return to /warp-qa-test or /warp-qa-debug. If CONDITIONAL, present the remaining issues to the user and get explicit approval to proceed.**
 
+### 1E. Verification Gate
+
+If ANY code was changed after the initial test run in Phase 1B (e.g., fixing diff review findings, addressing review comments, last-minute polish), re-run the full test suite before proceeding to commit.
+
+The Iron Law: "Should work now" is not evidence. Run it. "I'm confident the fix is correct" — confidence is not a test result.
+
+```
+VERIFICATION GATE:
+  Code changed after initial test run: [yes | no]
+  If yes:
+    Files modified: [list]
+    Reason: [review fix | polish | bug fix | other]
+    Re-run result: [N] passing, [N] failing
+    Gate: [PASS — all green | FAIL — fix and re-run]
+```
+
+This gate re-triggers whenever code changes. There is no limit to how many times it runs. The only exit is a clean test suite with zero changes after the last run.
+
+### 1F. Plan Completion Audit
+
+Read scope.md acceptance criteria and compare against what was actually built. Every AC gets an explicit status.
+
+```bash
+# Read scope acceptance criteria
+cat .warp/reports/planning/scope.md 2>/dev/null | head -100
+```
+
+```
+PLAN COMPLETION AUDIT:
+  Acceptance Criteria from scope.md:
+    1. [AC description] — DONE (evidence: [test name, file, or behavior])
+    2. [AC description] — NOT DONE (reason: [why] + user approved to ship without)
+    3. [AC description] — PARTIAL (what's done, what's missing)
+    ...
+
+  Summary: [N] DONE / [N] NOT DONE / [N] PARTIAL out of [N] total
+```
+
+**HARD GATE: User must explicitly approve shipping without any NOT DONE or PARTIAL items.** Present each incomplete AC and ask: "Ship without this? [Y/n]". If the user says no, return to build.
+
+### 1G. Distribution Pipeline Check
+
+If the architecture introduces a new standalone artifact (CLI binary, npm package, library, Docker image), check whether a release/publish workflow exists.
+
+```bash
+# Check for publish workflows
+ls -la .github/workflows/*publish* .github/workflows/*release* 2>/dev/null
+cat package.json 2>/dev/null | grep -E '"(name|publishConfig|bin|main|module|exports)"' || true
+ls -la Dockerfile* docker-compose* 2>/dev/null
+```
+
+```
+DISTRIBUTION CHECK:
+  Publishable artifacts detected: [list or "none"]
+  For each artifact:
+    Artifact: [name]
+    Registry: [npm | PyPI | crates.io | Docker Hub | etc.]
+    Publish workflow exists: [yes — path | no — FLAG]
+    Version in package file matches VERSION: [yes | no — FLAG]
+```
+
+If a publishable artifact has no release workflow, flag it: "No publish workflow detected for {artifact}. Create one before shipping, or document why manual publish is acceptable."
+
 ---
 
 ## PHASE 2: Diff Review
@@ -490,6 +578,25 @@ DIFF REVIEW SUMMARY:
 
 ### 3A. Version Bump
 
+Before bumping, run an idempotency check. This makes `/warp-release-update` safe to re-run after a partial failure (e.g., version was bumped but push failed, or PR was created but tests were re-run).
+
+```bash
+# Check current version state
+cat VERSION 2>/dev/null || echo "no VERSION file"
+git log --oneline -1 -- VERSION
+git rev-list --count @{u}..HEAD 2>/dev/null || echo "no upstream"
+gh pr list --head "$(git branch --show-current)" --json number,url --jq '.[0]' 2>/dev/null || echo "no PR"
+```
+
+```
+IDEMPOTENCY CHECK:
+  Version already bumped: [yes — skip bump | no — proceed]
+  Branch already pushed: [yes — skip push | no — proceed]
+  PR already exists: [yes — update body | no — create new]
+```
+
+If version is already bumped (VERSION file shows the target version), skip the bump and proceed to changelog verification. If branch is already pushed, skip push in Phase 4C. If a PR already exists, update the PR body in Phase 5 instead of creating a new one (`gh pr edit` instead of `gh pr create`).
+
 Determine the appropriate version bump:
 
 ```
@@ -567,6 +674,27 @@ STAGING REVIEW:
 
 ### 4B. Commit
 
+Analyze the diff and consider whether it should be split into logical, independently-valid commits. Each commit should pass tests on its own and be ordered by dependency:
+
+```
+COMMIT SPLIT ANALYSIS:
+  Total files changed: [N]
+  Suggested split:
+    1. [type]: [description] — [N] files (infrastructure / config)
+    2. [type]: [description] — [N] files (models / data layer)
+    3. [type]: [description] — [N] files (business logic / services)
+    4. [type]: [description] — [N] files (UI / components)
+    5. [type]: [description] — [N] files (tests)
+    6. [type]: [description] — [N] files (docs / VERSION)
+
+  Recommended: [split into N commits | single commit is fine]
+  Rationale: [why — e.g., "all changes are tightly coupled" or "infra + feature + tests are independent concerns"]
+```
+
+Dependency order for split commits: infrastructure → models → business logic → UI → tests → docs → VERSION. Each commit in the sequence should pass the test suite independently, making `git bisect` useful when tracking down regressions.
+
+If the user prefers a single commit, that is fine — but always offer the split for non-trivial diffs (5+ files or 3+ logical concerns).
+
 Create a meaningful commit (or verify commits are already clean from the polish phase):
 
 ```bash
@@ -856,7 +984,31 @@ API DOCS UPDATE CHECK:
   ☐ Error codes updated
 ```
 
-### 7E. Documentation Commit
+### 7E. TODOS.md Auto-Update
+
+After shipping, scan the diff against TODOS.md to keep the backlog honest.
+
+```bash
+# Read current TODOS
+cat TODOS.md 2>/dev/null || echo "no TODOS.md"
+```
+
+```
+TODOS.MD UPDATE:
+  Completed items detected from diff: [N]
+    - [item description] — completed by [commit/file evidence]
+    - [item description] — completed by [commit/file evidence]
+  Action: [check boxes | move to Completed section | leave as-is if none]
+
+  New TODO-worthy work created by this diff: [N]
+    - [description] — [why this is a TODO, not a bug]
+    - [description]
+  Action: [add to TODOS.md | skip if none]
+```
+
+Mark completed items (check the box or move to a Completed section, matching the project's TODOS.md format). Add new items only if the diff genuinely creates deferred work — do not manufacture TODOs.
+
+### 7F. Documentation Commit
 
 If any documentation was updated:
 
@@ -1143,6 +1295,28 @@ git log --format="%cd" --date=short --since="7 days ago" | sort | uniq -c
 
 Collect: commit history, files changed, hotspots (most-modified files), test file changes, new/deleted files.
 
+**Work Session Detection:** Detect coding sessions using a 45-minute gap threshold between consecutive commits. Two commits within 45 minutes of each other belong to the same session. A gap larger than 45 minutes starts a new session.
+
+```bash
+# Get commit timestamps for session detection
+git log --format="%H %ai" --since="7 days ago" | sort -k2,3
+```
+
+Classify each session:
+- **Deep** (>2 hours): sustained focus work, likely feature development or complex debugging
+- **Medium** (30 min — 2 hours): standard work sessions
+- **Micro** (<30 min): quick fixes, one-off commits, config changes
+
+```
+WORK SESSIONS:
+  Total sessions: [N]
+  Deep (>2hr): [N] sessions, [N] total hours
+  Medium (30min-2hr): [N] sessions, [N] total hours
+  Micro (<30min): [N] sessions
+  Total active hours: [N]
+  LOC per active hour: [N] (lines added + removed / active hours)
+```
+
 ### R2. Work Pattern Analysis
 
 **Commit pacing:** Distributed across the week (healthy) vs. burst-and-crash (warning). Flag 3+ day gaps or all commits on 1-2 days.
@@ -1151,6 +1325,63 @@ Collect: commit history, files changed, hotspots (most-modified files), test fil
 
 **Scope adherence:** Compare work done to TODOS.md priorities. Note emergent work (normal), scope creep (worth naming), distraction (address).
 
+**Hourly Commit Histogram:** Produce an ASCII bar chart of commits by hour of day. Identify peak hours, dead zones, and bimodal patterns (e.g., morning burst + late night session).
+
+```bash
+# Commits by hour
+git log --format="%H %ai" --since="7 days ago" | awk '{split($3,t,":"); print t[1]}' | sort | uniq -c | sort -k2 -n
+```
+
+```
+COMMIT HISTOGRAM (by hour):
+  00 |
+  01 |
+  ...
+  09 | ████████ (8)
+  10 | ████████████ (12)
+  11 | ██████ (6)
+  12 | ██ (2)
+  ...
+  21 | ██████████ (10)
+  22 | ████████████████ (16)
+  23 | ████ (4)
+
+  Peak hours: [list — e.g., 10:00, 22:00]
+  Dead zones: [list — e.g., 00:00-08:00, 12:00-14:00]
+  Pattern: [single peak | bimodal | distributed | nocturnal]
+```
+
+**Streak Tracking:** Count consecutive days with at least 1 commit. A streak is broken by a calendar day with zero commits.
+
+```bash
+# Commits per day (all time for streak, period for current)
+git log --format="%cd" --date=short | sort -u
+```
+
+```
+STREAK:
+  Current streak: [N] days (since [date])
+  Longest streak: [N] days ([start date] — [end date])
+  Days active this period: [N] / [N] total days
+  Activity rate: [N]%
+```
+
+**TODOS/Backlog Health:** Read TODOS.md and assess backlog health for the retro period.
+
+```bash
+cat TODOS.md 2>/dev/null || echo "no TODOS.md"
+```
+
+```
+BACKLOG HEALTH:
+  Total open items: [N]
+  P1 (critical/urgent) items: [N]
+  Items added this period: [N]
+  Items completed this period: [N]
+  Net change: [+N | -N | 0] (positive = backlog growing)
+  Health: [healthy (shrinking or stable) | warning (growing) | critical (P1 count > 3)]
+```
+
 ### R3. Code Quality Metrics
 
 ```bash
@@ -1190,6 +1421,61 @@ RETROSPECTIVE: {period}
   Actions: {3-5 assigned items}
 ```
 
+**JSON Snapshot Persistence:** Save retro metrics as JSON to `.warp/reports/releasing/retro-history.json` for trend comparison across retros. Append to the array — do not overwrite previous entries.
+
+```bash
+# Read existing history (or initialize)
+cat .warp/reports/releasing/retro-history.json 2>/dev/null || echo "[]"
+```
+
+Append a snapshot with this shape:
+
+```json
+{
+  "date": "YYYY-MM-DD",
+  "period": "YYYY-MM-DD to YYYY-MM-DD",
+  "commits": N,
+  "loc_added": N,
+  "loc_removed": N,
+  "files_changed": N,
+  "test_count": N,
+  "test_coverage_pct": N,
+  "quality_score": N,
+  "sessions": { "deep": N, "medium": N, "micro": N },
+  "active_hours": N,
+  "streak_current": N,
+  "streak_longest": N,
+  "backlog_open": N,
+  "backlog_p1": N,
+  "actions_completed": N,
+  "actions_total": N
+}
+```
+
+**Compare Mode:** If prior retro data exists in `retro-history.json`, show period-over-period deltas for key metrics. Use arrows to indicate direction.
+
+```
+TREND COMPARISON (vs. previous retro):
+  Commits:        [N] [↑ +3 | ↓ -2 | → same]
+  LOC (net):      [N] [↑ | ↓ | →]
+  Test count:     [N] [↑ | ↓ | →]
+  Coverage:       [N]% [↑ | ↓ | →]
+  Quality score:  [N]/10 [↑ | ↓ | →]
+  Active hours:   [N] [↑ | ↓ | →]
+  Streak:         [N]d [↑ | ↓ | →]
+  Backlog (open): [N] [↑ growing | ↓ shrinking | → stable]
+
+  Overall trajectory: [improving | stable | declining | mixed]
+```
+
+If no prior data exists, skip the comparison and note: "First retro — no prior data for comparison. Trends will appear after the next retro."
+
+**Tweetable Summary:** Produce a single-line summary suitable for a status update, team standup, or personal log.
+
+```
+TWEETABLE: Week of {date}: {N} commits, {N} LOC, {N}% tests, {N} files | Streak: {N}d | Quality: {N}/10
+```
+
 ---
 
 ## PUSH GATE

package/dist/warp-setup/SKILL.md

@@ -132,6 +132,8 @@ Shell commands use Unix syntax (Git Bash). Never use CMD (`dir`, `type`, `del`)
 
 ## AskUserQuestion
 
+**Flow: analysis first, then decision tool.** Present your full reasoning, trade-offs, and recommendations as conversational text — the user wants to read your thinking. Then cap it with AskUserQuestion to formalize the decision. **If you're composing a message with multiple options or "which approach?" language, you MUST end it with AskUserQuestion.** Never present options in prose without the tool.
+
 **Contract:**
 1. **Re-ground:** Project name, branch, current task. (1-2 sentences.)
 2. **Simplify:** Plain English a smart 16-year-old could follow.
@@ -153,9 +155,15 @@ Shell commands use Unix syntax (Git Bash). Never use CMD (`dir`, `type`, `del`)
 Format: `"Option name — X/10 🟢"` (or 🟡 or 🔴). In the label, not the description.
 Rate: 🟢 9-10 complete, 🟡 6-8 adequate, 🔴 1-5 shortcuts.
 
+**Pre-call checklist (verify before every AskUserQuestion invocation):**
+- ☐ Completeness scores in every option label
+- ☐ Recommended option listed first
+- ☐ One decision per question (split if multiple)
+- ☐ Analysis/reasoning already presented in message text above
+
 **Formatting:**
 - *Italics* for emphasis, not **bold** (bold for headers only).
-- After each answer: `✔ Decision {N} recorded [quicksave updated]`
+- After each answer: `✔ Decision {N} recorded`
 - Previews under 8 lines. Full mockups go in conversation text before the question.
 
 ---

package/dist/warp-upgrade/SKILL.md

@@ -128,6 +128,8 @@ Shell commands use Unix syntax (Git Bash). Never use CMD (`dir`, `type`, `del`)
 
 ## AskUserQuestion
 
+**Flow: analysis first, then decision tool.** Present your full reasoning, trade-offs, and recommendations as conversational text — the user wants to read your thinking. Then cap it with AskUserQuestion to formalize the decision. **If you're composing a message with multiple options or "which approach?" language, you MUST end it with AskUserQuestion.** Never present options in prose without the tool.
+
 **Contract:**
 1. **Re-ground:** Project name, branch, current task. (1-2 sentences.)
 2. **Simplify:** Plain English a smart 16-year-old could follow.
@@ -149,9 +151,15 @@ Shell commands use Unix syntax (Git Bash). Never use CMD (`dir`, `type`, `del`)
 Format: `"Option name — X/10 🟢"` (or 🟡 or 🔴). In the label, not the description.
 Rate: 🟢 9-10 complete, 🟡 6-8 adequate, 🔴 1-5 shortcuts.
 
+**Pre-call checklist (verify before every AskUserQuestion invocation):**
+- ☐ Completeness scores in every option label
+- ☐ Recommended option listed first
+- ☐ One decision per question (split if multiple)
+- ☐ Analysis/reasoning already presented in message text above
+
 **Formatting:**
 - *Italics* for emphasis, not **bold** (bold for headers only).
-- After each answer: `✔ Decision {N} recorded [quicksave updated]`
+- After each answer: `✔ Decision {N} recorded`
 - Previews under 8 lines. Full mockups go in conversation text before the question.
 
 ---
@@ -320,11 +328,20 @@ WARP │ UPGRADE
   Hooks:     patched ✓
   claude-mem: installed ✓
   Stale:     {N items cleaned / none}
-  Restart:   required
+  Restart:   {context-aware — see below}
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ```
 
-**Always remind:** "Restart Claude Code to pick up the new skills and hooks."
+### Restart guidance (context-aware)
+
+Skills are discovered dynamically — new skills are available immediately after install, no restart needed. Hooks fire on session lifecycle events (SessionStart, Stop, PreToolUse) — if hook *scripts* changed in this upgrade, a restart picks up the new behavior.
+
+Determine restart need:
+- **Hooks changed** (new hooks added, existing hooks modified) → `Restart: recommended (hooks updated)`
+- **Only skills/agents changed** → `Restart: not needed — new skills available now`
+- **Already current** (same version) → `Restart: not needed`
+
+When hooks changed, say: "Restart Claude Code to pick up updated hooks." When they didn't, say: "No restart needed — new skills are available now."
 
 ---
 
@@ -336,7 +353,7 @@ WARP │ UPGRADE
 - Check for and offer to clean stale artifacts
 - Verify claude-mem is installed
 - Show changelog summary
-- Remind user to restart Claude Code
+- Give context-aware restart guidance (hooks changed → recommend restart; skills only → no restart needed)
 
 **MUST NOT:**
 - Use git clone/pull to upgrade (npm handles distribution now)

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "warp-os",
-  "version": "1.1.2",
-  "description": "A development operating system for Claude Code. 16 skills compiled into a pipeline that thinks through every step of building a product.",
+  "version": "1.2.1",
+  "description": "A development operating system for Claude Code. 17 skills compiled into a pipeline that thinks through every step of building a product.",
   "author": "WolfOnWings",
   "license": "MIT",
   "repository": {

package/shared/project-hooks.json

@@ -26,6 +26,13 @@
         "hooks": [
           {"type": "command", "command": "echo 'Warp requires the Bash tool. All hooks and scripts are bash.' >&2; exit 2", "timeout": 5}
         ]
+      },
+      {
+        "matcher": "AskUserQuestion",
+        "description": "Warp: enforce completeness scores in option labels",
+        "hooks": [
+          {"type": "command", "command": "bash ~/.warp/hooks/validate-askuser.sh", "timeout": 5}
+        ]
       }
     ]
   }

package/shared/tier1-engineering-constitution.md

@@ -113,6 +113,8 @@ Shell commands use Unix syntax (Git Bash). Never use CMD (`dir`, `type`, `del`)
 
 ## AskUserQuestion
 
+**Flow: analysis first, then decision tool.** Present your full reasoning, trade-offs, and recommendations as conversational text — the user wants to read your thinking. Then cap it with AskUserQuestion to formalize the decision. **If you're composing a message with multiple options or "which approach?" language, you MUST end it with AskUserQuestion.** Never present options in prose without the tool.
+
 **Contract:**
 1. **Re-ground:** Project name, branch, current task. (1-2 sentences.)
 2. **Simplify:** Plain English a smart 16-year-old could follow.
@@ -134,9 +136,15 @@ Shell commands use Unix syntax (Git Bash). Never use CMD (`dir`, `type`, `del`)
 Format: `"Option name — X/10 🟢"` (or 🟡 or 🔴). In the label, not the description.
 Rate: 🟢 9-10 complete, 🟡 6-8 adequate, 🔴 1-5 shortcuts.
 
+**Pre-call checklist (verify before every AskUserQuestion invocation):**
+- ☐ Completeness scores in every option label
+- ☐ Recommended option listed first
+- ☐ One decision per question (split if multiple)
+- ☐ Analysis/reasoning already presented in message text above
+
 **Formatting:**
 - *Italics* for emphasis, not **bold** (bold for headers only).
-- After each answer: `✔ Decision {N} recorded [quicksave updated]`
+- After each answer: `✔ Decision {N} recorded`
 - Previews under 8 lines. Full mockups go in conversation text before the question.
 
 ---