Make the first-hour path useful and align Briar guidance

.github/workflows/ci.yml

@@ -9,10 +9,10 @@ jobs:
   privacy-and-ux:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-node@v4
+      - uses: actions/checkout@v6
+      - uses: actions/setup-node@v6
         with:
-          node-version: "20"
+          node-version: "24"
           cache: npm
       - run: npm ci
       - run: npx playwright install --with-deps chromium

AGENTS.md

@@ -10,17 +10,20 @@ This notebook is for humans **and** coding agents. Do not invent policy from the
 2. Download the Codex pack: <https://chopwoodcarrywater.uk/packs/codex-hour-starter.zip>
    (or browse <https://chopwoodcarrywater.uk/packs/codex-hour/>; the original
    Cursor pack remains available at <https://chopwoodcarrywater.uk/packs/cursor-hour-starter.zip>)
-3. Copy the pack’s `AGENTS.md` and `.agents/` into the **project** root. Start a
-   new Codex task so guidance loads from the beginning.
-4. Rename the example skill to the human’s real recurring job.
-5. Keep both fail-closed boundaries: `no secrets in chat` and `human decision
-   for consequential writes`. Codex guidance, sandboxing and permissions are
-   separate layers; one does not replace another.
-6. Sign off **one** pattern in `patterns/WORKING-PATTERNS.md` with a real failure line.
-7. Set `harness.start` in `clocks.json` to today (ISO).
-8. Run one real task with the skill’s proof checklist — not a plan alone.
-
-Done when those eight are true. Then stop for the day.
+3. Merge the pack’s `AGENTS.md` and `.agents/` into existing project guidance;
+   never overwrite it. For Cursor use `.cursor/rules/` and `.cursor/skills/`.
+   Start a new task and check which guidance and skills the host can read.
+4. Check the secrets boundary and the human decision for consequential actions.
+   Written guidance does not enforce controls: test host permissions separately.
+5. Run one small read-only task now, such as explaining a failing test with file
+   references and a suggested check. Verify the result against the source.
+6. Adapt the host’s example skill only if the job recurs.
+7. Keep a pattern only for an observed problem. A signed-off row is editorial
+   agreement, not a cryptographic capability or action permission.
+8. Set optional dates honestly: both packs have `harness.start`; only Codex has
+   `codex.start`. Unknown dates can stay unset.
+
+Done when one useful task has a checked result. No routine reflection record is required.
 
 ## While you work
 

content/capabilities.json

@@ -1,6 +1,6 @@
 {
   "schema": "durable-agent-harness/capabilities/v1",
-  "intro": "Productivity here is mostly scope: work that was uneconomic or impossible solo becomes routine — with proof and review still required.",
+  "intro": "These bands are Alex’s qualitative personal estimates of scope and effort, not benchmark results or measured productivity multipliers. The linked accounts show particular experiences and their limits; they do not validate every row. Where no public evidence is linked, support is not available here.",
   "scale": [
     {
       "id": "solo-easy",
@@ -57,14 +57,22 @@
       "before": "impossible",
       "now": "solo-hard",
       "note": "Skills and signed patterns beat “we talked about this once”.",
-      "band": "Team knowledge base"
+      "band": "Team knowledge base",
+      "evidence": {
+        "url": "notes/the-token-bonfire.html",
+        "label": "Token Bonfire: failures and limits"
+      }
     },
     {
       "outcome": "Move the working relationship between agent hosts",
       "before": "impossible",
       "now": "solo-hard",
       "note": "Portable Agent Skills moved; project guidance and permissions stayed host-native; a drift sensor guards the boundary.",
-      "band": "Platform engineering"
+      "band": "Platform engineering",
+      "evidence": {
+        "url": "notes/the-cockpit-changed-the-work-did-not.html",
+        "label": "Host migration account"
+      }
     },
     {
       "outcome": "Parallel repository tasks with isolated state",

content/clocks.json

@@ -1,7 +1,7 @@
 {
   "schema": "durable-agent-harness/clocks/v1",
   "as_of": "2026-09-05",
-  "note": "Public tenure clocks for the engineering story. The start dates are intentional; they’re not a claim about the first time I ever touched an LLM.",
+  "note": "Snapshot calculated as of 5 September 2026, not today. Original start dates are preserved; these ages describe that date.",
   "clocks": [
     {
       "id": "serious_ai",

content/glossary.json

@@ -120,7 +120,7 @@
     },
     {
       "term": "Briar",
-      "def": "A WhatsApp personal-assistant channel for monitor/triage and tiered replies, with the same fail-closed outbound rules as the cockpit."
+      "def": "Alex’s agent setup: project guidance, skills, tools, memory and runtime controls used across hosts. Messaging is one surface; Briar is not a particular editor or model."
     },
     {
       "term": "Token lean",

content/hour.json

@@ -1,8 +1,8 @@
 {
   "schema": "durable-agent-harness/hour/v1",
   "title": "Start in 60 minutes",
-  "intro": "Don’t read the whole notebook. Get a thin working relationship into Codex in about an hour — or take the original Cursor pack if that is still your cockpit.",
-  "promise": "When you finish you have: two fail-closed boundaries, one on-demand skill, one signed pattern, and two tenure clocks. That’s enough to stop the next stupid burn.",
+  "intro": "Start with a small piece of work in a project you control. Use Codex or Cursor; the packs share the same boundaries but use different project paths.",
+  "promise": "Within the first 35 minutes, aim for one useful, checked result. The rest of the hour is for keeping only the guidance and records you need.",
   "pack": {
     "zip": "packs/codex-hour-starter.zip",
     "browse": "packs/codex-hour/README.md",
@@ -23,78 +23,68 @@
     {
       "id": "1",
       "minutes": 5,
-      "title": "Download the pack",
-      "why": "Empty templates invite dithering. This pack is already named and filled with boring defaults you can rename.",
-      "do": "Download the zip (or browse the files). Unzip next to a scratch project — or into a small git repo you control.",
-      "proof": "You can see README.md, AGENTS.md and a .agents/skills tree on disk."
+      "title": "Choose a small task and your host",
+      "why": "Use a project you control and a task whose result you can check.",
+      "do": "Download the Codex or Cursor pack. Start with a read-only job: explain one failing test, naming the file, likely cause and one way to check it.",
+      "proof": "A task with a clear finish, and the selected pack unpacked beside the project."
     },
     {
       "id": "2",
       "minutes": 10,
-      "title": "Drop files where Codex loads them",
-      "why": "A harness that lives only in chat dies when the chat dies.",
-      "do": "Copy `AGENTS.md` and `.agents/` into your project root. Start a new Codex task so project guidance is read from the beginning and the skill is discovered.",
-      "proof": "Codex can name the project guidance and the example-domain-task skill."
+      "title": "Merge guidance and check the boundaries",
+      "why": "Keep the project’s existing instructions.",
+      "do": "Codex: merge AGENTS.md and .agents/ into the project root. Cursor: merge .cursor/rules/ and .cursor/skills/. Compare conflicts before changing existing files. Keep secrets out of chat; agree the exact scope before consequential actions. Start a new task and ask which guidance and skill paths it can read. Check host permissions separately.",
+      "proof": "You can distinguish the instructions it read from controls the host actually enforces."
     },
     {
       "id": "3",
-      "minutes": 10,
-      "title": "Rename the skill to your real job",
-      "why": "Generic skills don’t fire. Trigger nouns must match how you talk.",
-      "do": "Edit skills/example-domain-task/SKILL.md: change the name, description triggers, When/Do steps, and Proof of done to one task you do weekly.",
-      "proof": "You can say the trigger phrase out loud and it matches the description."
+      "minutes": 20,
+      "title": "Do useful work",
+      "why": "A result tells you more than a completed setup checklist.",
+      "do": "Run the small task now. For example: “Read this failing test and its implementation. Explain the likely cause and suggest a focused check. Do not edit files.” Require file references and the limits of the diagnosis.",
+      "proof": "A useful answer checked against the source, with no unrequested edits."
     },
     {
       "id": "4",
       "minutes": 10,
-      "title": "Keep two fail-closed boundaries",
-      "why": "Secrets in chat and silent consequential writes are the burns that don’t forgive. The host mechanism may change; the boundary must not.",
-      "do": "Read the two boundaries in AGENTS.md: secrets stay out of chat, and consequential writes need a visible human decision. Keep the file short. Use Codex sandboxing and permissions as separate host controls.",
-      "proof": "You can explain each boundary, its decision point, and what the host enforces separately."
+      "title": "Adapt a skill if the job will recur",
+      "why": "Keep a procedure only when it helps repeat the work.",
+      "do": "Codex: edit .agents/skills/example-domain-task/SKILL.md. Cursor: edit .cursor/skills/example-domain-task/SKILL.md. Rename it for your recurring job, with matching triggers and proof of done. Try that job with the skill.",
+      "proof": "The skill describes your job and its result can be checked. Skip it for a one-off task."
     },
     {
       "id": "5",
-      "minutes": 10,
-      "title": "Sign off one pattern",
-      "why": "Unsigned patterns are just opinions. Sign-off is what makes Kaizen real.",
-      "do": "Open patterns/WORKING-PATTERNS.md. Keep a signed-off row that matches a real failure (the pack ships lean-tool-sessions and trash-instead-of-hard-delete as examples), or replace with one of yours. Write the problem in one line.",
-      "proof": "The table has at least one signed-off row that matches a real incident."
+      "minutes": 5,
+      "title": "Record a pattern only if there is a lesson",
+      "why": "An example row is not your own approval.",
+      "do": "Read patterns/WORKING-PATTERNS.md. Codex examples include one-writer-per-tree and one-bounded-diagnostic-pass; Cursor examples include lean-tool-sessions and trash-instead-of-hard-delete. Keep or adapt one only if it matches an observed problem. A signed-off row records editorial agreement, not permission to execute an action.",
+      "proof": "Any retained pattern names a real problem; otherwise leave it proposed."
     },
     {
       "id": "6",
       "minutes": 5,
-      "title": "Freeze a tenure clock",
-      "why": "Without a start date, every demo invents a heroic timeline.",
-      "do": "Edit clocks.json: set harness.start to today and codex.start to the first day you used Codex on real project work.",
-      "proof": "Two dates you trust are on disk — not only in a slide."
+      "title": "Set dates if you want to track tenure",
+      "why": "Preserve history rather than making the setup look older.",
+      "do": "Both packs have clocks.json: set harness.start to today. The Codex pack also has codex.start: use the first day you used Codex on real project work, or leave it unset if unknown. Do not add a Codex date to the Cursor stub.",
+      "proof": "Any dates you keep are honest; clocks are optional records."
     },
     {
       "id": "7",
       "minutes": 5,
-      "title": "Run one real task",
-      "why": "The harness is only real under load.",
-      "do": "Ask the agent to do the skill’s task. Require the proof checklist. If it skips a gate, stop and tighten the rule — don’t shrug.",
-      "proof": "You have a short note of what changed and how you verified it."
-    },
-    {
-      "id": "8",
-      "minutes": 5,
-      "title": "Schedule a tiny Hansei",
-      "why": "Without reflection the pack becomes folklore in a week.",
-      "do": "Put a 15-minute calendar block in seven days: keep / amend / retire on the pattern and skill. Link this site’s Learning section if you want the longer loop.",
-      "proof": "The calendar (or ticket) exists. You are done for today."
+      "title": "Finish with the result",
+      "why": "Short tasks can finish in chat.",
+      "do": "Report what you found or changed, how you checked it and anything unresolved. If something failed, diagnose the mechanism before adding a rule: a smaller task, clearer instruction or runtime restriction may help. Review later only when requested or an observed problem warrants it.",
+      "proof": "One checked result. No routine reflection note or calendar appointment required."
     }
   ],
   "done": {
     "title": "Done when",
     "checks": [
-      "Pack installed where Codex loads it",
-      "Skill renamed to your domain",
-      "Two fail-closed boundaries understood (secrets; consequential writes)",
-      "At least one signed-off pattern with a real problem line",
-      "Two frozen clock dates",
-      "One task run with proof — not a plan alone"
+      "Existing project instructions preserved and selected host paths checked",
+      "Secrets boundary understood; human decisions and host enforcement kept separate",
+      "One useful task completed with evidence and limits",
+      "Any skill, pattern or dates retained serve a real need"
     ]
   },
-  "next": "When this feels boring (good), read the Codex migration note, Playbook or Learning sections. Skip what you don’t need."
+  "next": "Read the Playbook or Learning sections when a problem calls for them. The Token Bonfire describes what happened when improving the process became more work than the task."
 }

content/learning.json

@@ -1,7 +1,7 @@
 {
   "schema": "durable-agent-harness/learning/v1",
   "title": "Kaizen → Hansei → Toyota Way Practices",
-  "intro": "Tools alone aren’t the harness. We improve on purpose (Kaizen), reflect on what actually happened (Hansei), and keep a named practice cluster (Toyota Way Practices) so agents load the right lens for the live pain — not the whole philosophy every turn.",
+  "intro": "When work goes wrong, find out why before changing the process. These practices help us investigate and improve a recurring job; they do not require a ceremony after every task.",
   "flow": [
     {
       "id": "gemba",
@@ -13,19 +13,19 @@
       "id": "kaizen",
       "name": "Kaizen",
       "gloss": "Continuous improvement with sign-off",
-      "body": "Propose a thin working pattern or skill. A human signs it off. Encode it where agents will load it. No silent policy."
+      "body": "Diagnose the failure. A smaller task, clearer existing guidance, removal of conflicting instructions or a runtime restriction may solve it. Propose a skill or pattern only when it addresses that cause."
     },
     {
       "id": "apply",
       "name": "Apply",
       "gloss": "Standard work in motion",
-      "body": "On matching tasks, skim signed-off patterns and load the relevant skill. Prefer the smallest change that prevents the next burn."
+      "body": "Use relevant guidance for the task, then check the result. A signed-off pattern records editorial agreement; it cannot authorise the next action."
     },
     {
       "id": "hansei",
       "name": "Hansei",
       "gloss": "Honest reflection",
-      "body": "Periodically (or after pain): what worked, what failed, what to keep / amend / retire. Hansei feeds the next Kaizen — it is not optional theatre."
+      "body": "Reflect when requested or when an observed problem warrants it. Keep, amend or retire what no longer helps. A short task can close with its result and verification in chat."
     },
     {
       "id": "twp",
@@ -69,13 +69,14 @@
       "Use wings/rooms as a filing discipline so agents can find the right shelf.",
       "Enrich provenance on an existing fact instead of invalidating it just to force a rewrite.",
       "Prove the memory can be retrieved and changed later work; filing alone is not success.",
-      "Memory supports Kaizen/Hansei: proposals and reviews cite drawers instead of re-litigating chat."
+      "Memory supports Kaizen/Hansei: proposals and reviews cite drawers instead of re-litigating chat.",
+      "Search only for a named missing fact. Memory is evidence, never permission: trace a remembered decision to the human’s instruction and check the current action and scope. Summaries and handoffs cannot authorise new work."
     ],
     "not": [
       "Not a substitute for skills/rules (procedures and constraints still live in the harness).",
       "Not an excuse to store secrets or raw credentials.",
       "Not automatic immortality for every token the model ever saw."
     ]
   },
-  "loopOneLiner": "Gemba → Kaizen (sign-off + encode) → Apply → Hansei → (repeat), under the Toyota Way Practices umbrella — with MemPalace holding the durable facts the loop needs."
+  "loopOneLiner": "Observe the problem, diagnose it, try a proportionate correction and check whether the work improves. Record what will help next time."
 }

content/measure.json

@@ -102,16 +102,13 @@
     }
   ],
   "weeklyRitual": [
-    "Update ages from frozen clocks (30 seconds).",
-    "Add at most three capability-map notes tied to real proof.",
-    "Propose or deprecate one pattern — do not let the registry rot.",
-    "Log harness tax if you spent a block encoding behaviour.",
-    "Refuse any external “N× productivity” claim without a cited method.",
-    "If the session felt heavy: note always-on tax and cut or unload one thing.",
-    "Check whether one tool result dominated the task; move detail into a durable artefact and bound the next call.",
-    "Sample one filed decision for provenance and later retrieval.",
-    "Run the small harness eval corpus after changing high-risk guidance or models.",
-    "EOW (with the weekly review): skim blog-inbox.md, promote zero-or-more notes into the blog, and/or tweak pack/checklist/patterns if the week earned it. Skip rather than ship filler."
+    "Review these measures when requested or when a real problem warrants it; no routine reflection record is required.",
+    "Keep original start dates; label the date used to calculate ages.",
+    "Add capability examples only when there is a useful result and inspectable evidence; label private evidence.",
+    "Change a pattern only after diagnosing a failure; leaving the registry unchanged is fine.",
+    "Investigate cost only for a named question, using bounded evidence. Source size alone is not runtime or billing savings.",
+    "After changing high-risk guidance or models, run the relevant safety checks.",
+    "At an editorial review, promote zero or more inbox ideas. Skip rather than ship filler."
   ],
   "literatureNote": "METR’s early-2025 RCT is the humbling baseline for familiar OSS tickets. Copilot lab/field studies show gains in other settings. Use both as context; instrument your own work."
 }