odd-studio 2.2.0 → 2.3.0

package/bin/odd-studio.js

@@ -62,7 +62,7 @@ program
     console.log(chalk.bold(`  Setting up: ${chalk.cyan(resolvedName)}\n`));
 
     // 1. Scaffold project structure
-    print.step(1, 4, 'Creating project structure...');
+    print.step(1, 5, 'Creating project structure...');
     const spinner1 = ora({ text: '', indent: 4 }).start();
     try {
       await scaffoldProject(targetDir, resolvedName);
@@ -76,7 +76,7 @@ program
 
     // 2. Install /odd skill
     if (!options.skipSkill) {
-      print.step(2, 4, 'Installing /odd skill into Claude Code...');
+      print.step(2, 5, 'Installing /odd skill into Claude Code...');
       const spinner2 = ora({ text: '', indent: 4 }).start();
       try {
         const result = await installSkill(PACKAGE_ROOT);
@@ -88,13 +88,13 @@ program
         print.info('Manual install: copy ' + chalk.dim('skill/') + ' to ' + chalk.dim('~/.claude/skills/odd/'));
       }
     } else {
-      print.step(2, 4, 'Skipping skill install (--skip-skill)');
+      print.step(2, 5, 'Skipping skill install (--skip-skill)');
       print.warn('Remember to install the skill manually for /odd to work in Claude Code.');
     }
 
     // 3. Setup hooks
     if (!options.skipHooks) {
-      print.step(3, 4, 'Installing safety hooks into Claude Code settings...');
+      print.step(3, 5, 'Installing safety hooks into Claude Code settings...');
       const spinner3 = ora({ text: '', indent: 4 }).start();
       try {
         const result = await setupHooks(PACKAGE_ROOT);
@@ -106,7 +106,7 @@ program
         print.info('Manual install: add entries from ' + chalk.dim('hooks/') + ' to ~/.claude/settings.json');
       }
     } else {
-      print.step(3, 4, 'Skipping hooks (--skip-hooks)');
+      print.step(3, 5, 'Skipping hooks (--skip-hooks)');
       print.warn('Safety hooks not installed. Git guardrails and quality gates will not run.');
     }
 
@@ -152,8 +152,9 @@ program
     if (projectName) {
       console.log('  1. ' + chalk.cyan(`cd ${projectName}`));
     }
-    console.log('  ' + (projectName ? '2' : '1') + '. Open Claude Code: ' + chalk.cyan('claude .'));
-    console.log('  ' + (projectName ? '3' : '2') + '. Start your ODD session: ' + chalk.cyan('/odd'));
+    console.log('  ' + (projectName ? '2' : '1') + '. Restart Claude Code: ' + chalk.cyan('quit and reopen') + chalk.dim(' (activates ruflo memory + hooks)'));
+    console.log('  ' + (projectName ? '3' : '2') + '. Open your project: ' + chalk.cyan('claude .'));
+    console.log('  ' + (projectName ? '4' : '3') + '. Start your ODD session: ' + chalk.cyan('/odd'));
     print.blank();
 
     console.log(chalk.dim('  ODD Studio implements Outcome-Driven Development.'));

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "odd-studio",
-  "version": "2.2.0",
+  "version": "2.3.0",
   "description": "Outcome-Driven Development for Claude Code — a planning and build harness for domain experts building serious software with AI.",
   "keywords": [
     "claude-code",

package/scripts/postinstall.js

@@ -22,6 +22,7 @@ Promise.all([
 ])
   .then(() => {
     console.log('✓ ODD Studio: /odd skill, safety hooks, and ruflo memory installed into Claude Code');
+    console.log('  → Restart Claude Code now to activate ruflo memory and hooks.');
     console.log('  Run: npx odd-studio init [project-name]  to scaffold your first project.');
   })
   .catch((e) => {

package/skill/docs/chapters/chapter-10.md

@@ -8,7 +8,7 @@ The Build Protocol is the repeating rhythm of every session. It is deliberately
 
 - **The tool handles the mechanics. You handle the judgment.** ODD Studio loads context from ruflo, reads the contract map, identifies the next outcome to build, briefs the AI, waits for the result, and presents you with a verification checklist. Your job is to follow that checklist as the persona and judge whether the result is correct.
 
-- **The session rhythm is: /odd, *build, verify, confirm.** `/odd` loads the skill and restores project state from ruflo. `*build` starts the next outcome. You verify the result against the checklist. `confirm` commits the verified outcome and advances to the next one. That is it.
+- **The session rhythm is: /odd, *build, verify, confirm.** `/odd` loads the skill and restores project state from ruflo. `*build` starts the next outcome. You verify the result against the checklist. `confirm` runs Checkpoint (a security scan of what was just built), commits the verified outcome, and advances to the next one. That is it.
 
 - **Re-briefing is automatic.** You do not need to remind the AI what your project is, what has been built, or what comes next. Ruflo stores all of this. ODD Studio reads it at the start of every session. If you find yourself explaining context, something is wrong with the state — not with the process.
 
@@ -22,6 +22,8 @@ The Build Protocol is the repeating rhythm of every session. It is deliberately
 
 - Building without verifying. Typing `confirm` without following the verification checklist is the fastest way to accumulate hidden defects. Every unverified outcome is a risk to every outcome that depends on it.
 
+- Worrying about security implementation. Checkpoint runs automatically when you type `confirm`. It scans for exposed secrets, missing authentication checks, and injection vulnerabilities in what was just built. If it finds something, the build agent fixes it before the commit. You do not need to think about this — it happens in the background.
+
 - Batching multiple outcomes into one build. Each outcome has its own verification checklist for a reason. Mixing them makes it impossible to know which outcome caused a failure.
 
 ## What This Means for You

package/skill/docs/chapters/chapter-11.md

@@ -10,6 +10,16 @@ Automated tests confirm the code does what it was told. Verification confirms it
 
 - **Verification is done as the persona.** You are not checking as yourself — you are checking as the persona in their situation. If the persona is on a phone with limited time, verify on a phone. If the persona is a first-time user, approach the interface as if you have never seen it.
 
+## What You Verify vs. What Checkpoint Verifies
+
+There are two kinds of correctness in a verified outcome. You are responsible for one. Checkpoint handles the other.
+
+**You verify domain correctness.** Does this outcome do what the persona needs it to do? Does the email contain the right information? Does the booking flow make sense to a first-time user? Does the error message explain what went wrong in plain language? Only you can answer these questions. No tool can.
+
+**Checkpoint verifies security correctness.** Did the build introduce an exposed credential? Is there a path that bypasses authentication? Could an input be used to extract data it should not be able to reach? Checkpoint scans for these automatically every time you type `confirm`. You do not need to think about them. They are not part of your verification checklist.
+
+This division of labour is deliberate. You are good at judging whether something is right for your users. You are not expected to know what an injection vulnerability looks like in code. Checkpoint is good at finding those. Neither replaces the other.
+
 ## Three Rules of Verification
 
 - **Don't skip steps.** Every step in the checklist tests a specific part of the outcome. Skipping a step means that part is unverified. Unverified parts fail in production.

package/skill/docs/chapters/chapter-12.md

@@ -16,13 +16,13 @@ No new principles here. Everything has been introduced in earlier chapters. This
 
 **Step 5: Failure handling.** When you describe a failure, ODD Studio handles the fix. It re-reads the specification, makes the correction, and presents the checklist again. You verify again from the beginning — a partial re-verification does not count.
 
-**Step 6: confirm.** When every step passes, you type `confirm`. ODD Studio commits the verified outcome to git, updates ruflo with the new project state, and advances the plan to the next outcome. The cycle is complete.
+**Step 6: confirm.** When every step passes, you type `confirm`. Before committing, ODD Studio runs Checkpoint — a security scan of what was just built. If Checkpoint finds anything, the build agent fixes it quietly and Checkpoint runs again. You see "Checkpoint clear" when it passes. ODD Studio then commits the verified outcome to git, updates ruflo with the new project state, and advances the plan to the next outcome. The cycle is complete.
 
 ## What You Do vs. What the Tool Does
 
 **You do:** verify the result as the persona. Describe failures in domain language. Confirm when satisfied.
 
-**The tool does:** load context, brief the AI, run the build, present the checklist, handle fixes, commit, update state.
+**The tool does:** load context, brief the AI, run the build, present the checklist, handle fixes, run Checkpoint, brief the build agent on any security findings, commit, update state.
 
 ## Red Flags
 

package/skill/docs/chapters/chapter-14.md

@@ -22,10 +22,40 @@ The feeling that security is "too technical" is understandable but incorrect. Se
 
 - Security treated as a separate phase. Security outcomes are not an add-on. They belong in the same phase as the outcomes they constrain. The "view grades" permission outcome and the "block unauthorised grade access" prohibition outcome should be built and verified together.
 
+## Checkpoint: The Security Layer You Do Not Have to Think About
+
+Domain security — who can see what, who can do what — is your responsibility. You specify it as outcomes and verify it as the persona.
+
+Implementation security is a different category. It covers things like: a credential accidentally left in the code by the AI, a route that can be reached without authentication because the AI made a wrong assumption, an input field that accepts data it should reject. These are not failures of specification. They are failures of implementation that you would have no way to spot by reading code or clicking through a verification checklist.
+
+This is what Checkpoint handles. Every time you type `confirm`, Checkpoint scans what was just built. It looks for exposed secrets, missing authentication checks, unsafe inputs, and known vulnerability patterns. If it finds something, it briefs the build agent with specific fix instructions in plain language. The fix happens, Checkpoint scans again, and the cycle repeats until it is clean. You see one message: "Checkpoint clear." Then the outcome is committed.
+
+You do not need to understand what Checkpoint found. You do not need to review the fix. That is not your job. Your job is the domain. Checkpoint's job is the implementation layer.
+
+The result is that every committed outcome in your project has been verified twice: once by you for domain correctness, and once by Checkpoint for implementation security. Neither check replaces the other, and neither is optional.
+
+## Two Types of Security Work
+
+To be precise about the division:
+
+**Your security work** (done during outcome writing and verification):
+- Write prohibition outcomes for every permission outcome
+- Verify that the wrong persona cannot access restricted data
+- Verify that direct URL access is blocked, not just hidden
+- Ensure data deletion outcomes exist wherever data is collected
+
+**Checkpoint's security work** (done automatically at `confirm`):
+- Detect exposed credentials and secrets in code
+- Detect missing or bypassed authentication checks
+- Detect injection vulnerabilities and unsafe inputs
+- Detect known vulnerability patterns from security databases
+
+Do both. Neither is enough alone.
+
 ## What This Means for You
 
 For every outcome that involves access to data or actions restricted to certain personas, write the corresponding prohibition outcome. Then verify both: check that the right persona can do the thing, and check that the wrong persona cannot.
 
-You already know who should see what in your system. Write it down in outcome format. That is all security requires from you.
+You already know who should see what in your system. Write it down in outcome format. Checkpoint will handle the rest of the security picture automatically.
 
 Next: Chapter 15 shows that interface quality is a specification problem — and gives you five principles to specify it.