From 3f445bd1b149bd40c617e4a4d05be28ae8955a2f Mon Sep 17 00:00:00 2001 From: klappy <118073+klappy@users.noreply.github.com> Date: Thu, 3 Sep 2026 04:14:46 +0000 Subject: [PATCH 1/4] =?UTF-8?q?canon(methods):=20driver-seat-pass=20?= =?UTF-8?q?=E2=80=94=20the=20captain's=20prompt=20as=20a=20planning=20life?= =?UTF-8?q?cycle=20step=20(DRAFT;=20HUMAN-ONLY=20voice=20review)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- canon/methods/driver-seat-pass.md | 182 ++++++++++++++++++++++++++++++ 1 file changed, 182 insertions(+) create mode 100644 canon/methods/driver-seat-pass.md diff --git a/canon/methods/driver-seat-pass.md b/canon/methods/driver-seat-pass.md new file mode 100644 index 00000000..4b01eed6 --- /dev/null +++ b/canon/methods/driver-seat-pass.md @@ -0,0 +1,182 @@ +--- +uri: klappy://canon/methods/driver-seat-pass +title: "The Driver's-Seat Pass — A Planning Seat Sits Where the Agent Will Sit Before the Plan Binds" +audience: canon +exposure: nav +tier: 2 +voice: neutral +stability: evolving +status: draft +tags: ["canon", "methods", "planning", "ergonomics", "agent-legibility", "lifecycle", "receipt", "driver-seat"] +epoch: E0010 +date: 2026-09-03 +derives_from: "canon/bootstrap/model-operating-contract.md, canon/values/axioms.md, canon/constraints/mode-discipline-and-bottleneck-respect.md" +complements: "canon/methods/revision-lens-sequence.md, canon/constraints/borrow-evaluation-before-implementation.md, canon/constraints/reviewability-standard.md, canon/constraints/infra-config-is-seat-work.md" +governs: "Every meal, entrée, catering plate, and plan revision in a kitchen that inherits this canon: before the plan binds, a planning seat runs the captain's driver's-seat prompt over the whole design set and leaves a DELTA receipt" +target_repo: "outcomes-driven-development" +--- + + +# The Driver's-Seat Pass — A Planning Seat Sits Where the Agent Will Sit Before the Plan Binds + +> Before a plan binds, one planning seat reads the whole design set as the +> agent who will have to drive it, and changes the documents until the system +> is legible, coherent, and cheap from that seat. The pass is the constructive +> twin of `oddkit_challenge`: challenge finds what is wrong; the pass finds +> what is missing. It runs on meals, entrées, catering plates, and every plan +> revision; it leaves a `DELTA.md` naming what changed and what was considered +> and rejected. A pass that leaves no delta did not run. Captain, 2026-09-02: +> "that needs to be a policy run on all tickets and planning loops." + +--- + +## WHAT — The Rule, Precisely + +**The prompt.** The pass is the captain's prompt, run verbatim by a planning +seat with the plan and every design document in context. The text is the +captain's and is not edited by any seat (HUMAN-ONLY: voice): + +> OK, now I want you to think deeply about how to make this entire system as +> agent-intuitive, agent-ergonomic, and agent-accretive as you can possibly +> imagine. Put yourself in the driver's seat and imagine that YOU are the one +> using this system and driving it. What would most enable you to do an +> awesome job understanding the situation accurately and optimally controlling +> everything to drive the best and most accurate results possible, with the +> least expenditure of resources? +> +> Then make all the requisite changes to the various design documents and +> plans accordingly. Don't just think of the project as an assemblage of +> various parts or components: really try to profoundly and deeply +> conceptualize it as a synthetic SYSTEM that is maximally coherent, cohesive, +> modular, and interconnected, forming a tower of linked abstractions that are +> maximally legible to you as an agent. Really ruminate and meditate on all of +> this incredibly deeply before responding or taking any actions. + +**The run.** A capable planning seat (Fable class or better) takes the +ticket, its plan, and every design document the plan touches into one +context and runs the prompt as written, in exploration → planning modes +only. No execution. The output is two things: + +1. Edits to the design documents themselves, made by the seat. +2. `DELTA.md` beside the ticket: for each thing the pass changed, one line + naming the change and why; for each thing it considered and rejected, one + line naming it and the reason; and a picture of the system as one thing + ("the tower"), not as a parts list. + +**Order.** The pass runs *before* `oddkit_challenge`. The pass finds what is +missing; the challenge then finds what is wrong with the plan the pass left. +Running them the other way spends challenge's questions on a plan about to +be rewritten. + +**Voice.** The pass edits plans and seat-authored documents. A document in the +captain's voice is not edited by the pass; the proposed change is named in +`DELTA.md` and the pass stops there. + +--- + +## WHY — Rationale and the Motivating Failure + +The prompt already worked once. On 2026-09-02 it was run in chat over +`klappy/door43-mcp` and produced PR #1 (`a32ea6d`): `AGENTS.md`, the +response envelope, the docs ladder, projection-not-semantics, and teaching +errors — the revision that made the server's first three gates cheap to +build. That run was unprompted by any policy and recorded as no step. A +prompt that works once in chat and lives nowhere on the rail is the +rule-in-memory class (kitchen journal k0033): it runs when someone remembers +it and stops the day they do not. + +The pass earns its place because the questions it asks are not the ones the +other gates ask. The order checklist asks whether the fields are there. The +challenge asks whether the claims survive pressure. Neither asks the +planning seat to sit where the agent will sit and say what would make the +job cheap. That is a substance read from a particular chair, and it needs +its own step so it is run every time and not when convenient. + +--- + +## ENFORCEMENT — The Named Enforcer, Honestly Graded + +This is a lifecycle step with a file receipt, enforced at the ticket gate: + +- **Wire (L4):** the kitchen's `cookbook/tickets/LIFECYCLE.md` step 3 names + when the pass runs; `cookbook/tickets/CHECKLIST.md` gate 13 ("Pass + receipt") reads whether `DELTA.md` exists beside the ticket or the ticket + carries `driver-seat: exempt ()`. A scoped ticket with neither is + not bound. The boarding shim carries one line pointing here. +- **What this does and does not enforce.** Gate 13 reads file presence. It + cannot read whether the delta is real. A `DELTA.md` that says "looks good" + passes the gate and fails the pass; the Failure Modes below name the + response. Under the enforcement ladder this is honest L3/L4 territory: a + seat can comply by remembering to write a file, so the gate is a tripwire, + not an enforcer. The interim obligation is the receipt's shape — a DELTA + with no named change and no named rejection is malformed on its face, and + the health inspection may lint for that. + +--- + +## SCOPE — The Governed Surface + +- **Runs on:** meals, entrées, catering plates, and every plan revision to + one of those. A revision without a fresh `DELTA.md` is a plan that changed + with no one in the seat. +- **Exempt by default:** fast-food (one-line dishes) and petit fours. The + exemption is written in the ticket, not assumed. +- **Widening is the captain's ruling, not the seat's.** The captain may put + the pass on every plate. The seat does not widen scope on its own and does + not narrow it to save cost. +- **Cost:** one planning-seat turn on a capable model per scoped plate or + revision. Scope stays proportional to that cost, or the rule dies of it. + +--- + +## VERIFICATION — How Compliance Is Proven + +- A planning seat can `oddkit_get klappy://canon/methods/driver-seat-pass` + and observe the prompt verbatim plus when and on what to run it. +- A cook can run the kitchen CHECKLIST on an entrée and observe gate 13 pass + only with a `DELTA.md` present or an explicit exemption line. +- The captain can read this file and find the prompt is his text, unedited. +- A reader can open the folder of the first scoped ticket after it plates + (`klappy/kitchen` `2026-09-02-door43-mcp-v2-planning`) and observe a + `DELTA.md` with named changes and named rejections. +- **Falsifier / retraction condition:** if two consecutive scoped plates + carry `DELTA.md` files that change nothing the challenge would not also + have caught, the pass is not earning its turn — scope narrows by ruling, or + the step retracts and this document is superseded, not deleted. + +--- + +## Failure Modes — What Breaks When the Pass Is a Vibe + +- **Re-read, not a pass:** the seat reads the docs and writes "looks good" + — no delta. +- **Scope creep by cost:** the pass runs on fast-food, gets expensive, and + the rule is dropped for everything. +- **Voice edit:** the pass rewrites a captain-voice document because it was + in context. +- **Wrong order:** challenge runs first and its findings are made stale by + the pass. + +## Required Response When Detected + +- **Empty delta** → gate 13 fails; the pass is re-run with the docs *and* a + list of every call the seat would make as the user of the system. +- **Cost** → scope stays proportional; the captain widens it by ruling, not + the seat. +- **Voice** → stop; revert the edit; name the proposed change in `DELTA.md` + and show the exact text. +- **Wrong order** → re-run challenge on the post-pass plan; the earlier run + is noted in DELTA as pre-pass. + +## See Also + +- [Model Operating Contract](/canon/bootstrap/model-operating-contract.md) — + the four modes; the pass lives at the planning → execution boundary +- [Revision Lens Sequence](/canon/methods/revision-lens-sequence.md) — + single-lens passes verify; the driver's-seat pass is one such lens +- [Borrow Evaluation Before Implementation](/canon/constraints/borrow-evaluation-before-implementation.md) + — the other planning-time table a plan owes before it fires +- [Infra Config Is Seat Work](/canon/constraints/infra-config-is-seat-work.md) + — the sibling L1 landed the same night, same class of recurring miss +- Kitchen wire: `klappy/kitchen` `cookbook/tickets/LIFECYCLE.md` (step 3), + `cookbook/tickets/CHECKLIST.md` (gate 13) From 374018fbdea38ef8e3640e46c6f0b53001d3a62b Mon Sep 17 00:00:00 2001 From: klappy <118073+klappy@users.noreply.github.com> Date: Thu, 3 Sep 2026 04:26:35 +0000 Subject: [PATCH 2/4] =?UTF-8?q?canon(methods):=20driver-seat-pass=20?= =?UTF-8?q?=E2=80=94=20metaphor-agnostic=20recut;=20kitchen/ARS=20moved=20?= =?UTF-8?q?to=20Example=20Applications=20(captain=20ruling=202026-09-03)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- canon/methods/driver-seat-pass.md | 180 ++++++++++++++++++------------ 1 file changed, 106 insertions(+), 74 deletions(-) diff --git a/canon/methods/driver-seat-pass.md b/canon/methods/driver-seat-pass.md index 4b01eed6..1984eef2 100644 --- a/canon/methods/driver-seat-pass.md +++ b/canon/methods/driver-seat-pass.md @@ -7,34 +7,34 @@ tier: 2 voice: neutral stability: evolving status: draft -tags: ["canon", "methods", "planning", "ergonomics", "agent-legibility", "lifecycle", "receipt", "driver-seat"] +tags: ["canon", "methods", "planning", "ergonomics", "agent-legibility", "lifecycle", "receipt", "driver-seat", "metaphor-agnostic"] epoch: E0010 date: 2026-09-03 derives_from: "canon/bootstrap/model-operating-contract.md, canon/values/axioms.md, canon/constraints/mode-discipline-and-bottleneck-respect.md" complements: "canon/methods/revision-lens-sequence.md, canon/constraints/borrow-evaluation-before-implementation.md, canon/constraints/reviewability-standard.md, canon/constraints/infra-config-is-seat-work.md" -governs: "Every meal, entrée, catering plate, and plan revision in a kitchen that inherits this canon: before the plan binds, a planning seat runs the captain's driver's-seat prompt over the whole design set and leaves a DELTA receipt" +governs: "Any governed body of work, under any operating metaphor: before a plan of substantive size binds, a planning seat runs the operator's driver's-seat prompt over the whole design set and leaves a delta receipt" target_repo: "outcomes-driven-development" --- - # The Driver's-Seat Pass — A Planning Seat Sits Where the Agent Will Sit Before the Plan Binds > Before a plan binds, one planning seat reads the whole design set as the > agent who will have to drive it, and changes the documents until the system > is legible, coherent, and cheap from that seat. The pass is the constructive > twin of `oddkit_challenge`: challenge finds what is wrong; the pass finds -> what is missing. It runs on meals, entrées, catering plates, and every plan -> revision; it leaves a `DELTA.md` naming what changed and what was considered -> and rejected. A pass that leaves no delta did not run. Captain, 2026-09-02: -> "that needs to be a policy run on all tickets and planning loops." +> what is missing. It runs on every unit of work above the trivial, and on +> every revision of such a plan; it leaves a delta receipt naming what changed +> and what was considered and rejected. A pass that leaves no delta did not +> run. Operator, 2026-09-02: "that needs to be a policy run on all tickets +> and planning loops." --- ## WHAT — The Rule, Precisely -**The prompt.** The pass is the captain's prompt, run verbatim by a planning +**The prompt.** The pass is the operator's prompt, run verbatim by a planning seat with the plan and every design document in context. The text is the -captain's and is not edited by any seat (HUMAN-ONLY: voice): +operator's and is not edited by any seat (HUMAN-ONLY: voice): > OK, now I want you to think deeply about how to make this entire system as > agent-intuitive, agent-ergonomic, and agent-accretive as you can possibly @@ -52,16 +52,16 @@ captain's and is not edited by any seat (HUMAN-ONLY: voice): > maximally legible to you as an agent. Really ruminate and meditate on all of > this incredibly deeply before responding or taking any actions. -**The run.** A capable planning seat (Fable class or better) takes the -ticket, its plan, and every design document the plan touches into one -context and runs the prompt as written, in exploration → planning modes -only. No execution. The output is two things: +**The run.** A capable planning seat takes the work unit, its plan, and every +design document the plan touches into one context and runs the prompt as +written, in exploration → planning modes only. No execution. The output is +two things: 1. Edits to the design documents themselves, made by the seat. -2. `DELTA.md` beside the ticket: for each thing the pass changed, one line - naming the change and why; for each thing it considered and rejected, one - line naming it and the reason; and a picture of the system as one thing - ("the tower"), not as a parts list. +2. **The delta receipt** — a file stored with the work unit (`DELTA.md` by + convention): for each thing the pass changed, one line naming the change + and why; for each thing it considered and rejected, one line naming it and + the reason; and a picture of the system as one thing, not as a parts list. **Order.** The pass runs *before* `oddkit_challenge`. The pass finds what is missing; the challenge then finds what is wrong with the plan the pass left. @@ -69,8 +69,15 @@ Running them the other way spends challenge's questions on a plan about to be rewritten. **Voice.** The pass edits plans and seat-authored documents. A document in the -captain's voice is not edited by the pass; the proposed change is named in -`DELTA.md` and the pass stops there. +operator's voice is not edited by the pass; the proposed change is named in +the delta receipt and the pass stops there. + +**Vocabulary.** This method names three things and nothing else: a *work +unit* (the thing being planned), a *planning seat* (whoever runs the pass), +and a *delta receipt* (the file that proves it ran). Every operating +metaphor supplies its own words for the work unit, its size classes, its +lanes, and its gates. The method binds to none of them; see Example +Applications. --- @@ -79,70 +86,92 @@ captain's voice is not edited by the pass; the proposed change is named in The prompt already worked once. On 2026-09-02 it was run in chat over `klappy/door43-mcp` and produced PR #1 (`a32ea6d`): `AGENTS.md`, the response envelope, the docs ladder, projection-not-semantics, and teaching -errors — the revision that made the server's first three gates cheap to +errors — the revision that made the server's first three milestones cheap to build. That run was unprompted by any policy and recorded as no step. A -prompt that works once in chat and lives nowhere on the rail is the -rule-in-memory class (kitchen journal k0033): it runs when someone remembers -it and stops the day they do not. +prompt that works once in chat and lives nowhere durable is the +rule-in-memory class: it runs when someone remembers it and stops the day +they do not. The pass earns its place because the questions it asks are not the ones the -other gates ask. The order checklist asks whether the fields are there. The -challenge asks whether the claims survive pressure. Neither asks the -planning seat to sit where the agent will sit and say what would make the -job cheap. That is a substance read from a particular chair, and it needs -its own step so it is run every time and not when convenient. +other gates ask. A form check asks whether the fields are there. A challenge +asks whether the claims survive pressure. Neither asks the planning seat to +sit where the agent will sit and say what would make the job cheap. That is +a substance read from a particular chair, and it needs its own step so it is +run every time and not when convenient. --- ## ENFORCEMENT — The Named Enforcer, Honestly Graded -This is a lifecycle step with a file receipt, enforced at the ticket gate: - -- **Wire (L4):** the kitchen's `cookbook/tickets/LIFECYCLE.md` step 3 names - when the pass runs; `cookbook/tickets/CHECKLIST.md` gate 13 ("Pass - receipt") reads whether `DELTA.md` exists beside the ticket or the ticket - carries `driver-seat: exempt ()`. A scoped ticket with neither is - not bound. The boarding shim carries one line pointing here. -- **What this does and does not enforce.** Gate 13 reads file presence. It - cannot read whether the delta is real. A `DELTA.md` that says "looks good" - passes the gate and fails the pass; the Failure Modes below name the - response. Under the enforcement ladder this is honest L3/L4 territory: a - seat can comply by remembering to write a file, so the gate is a tripwire, - not an enforcer. The interim obligation is the receipt's shape — a DELTA - with no named change and no named rejection is malformed on its face, and - the health inspection may lint for that. +This method is a lifecycle step with a file receipt. It is enforced wherever +the adopting system already gates a plan before it binds: + +- **What canon asks of the adopter.** Name the step in the adopter's own + planning lifecycle at the point just before bind; add one gate to the + adopter's own pre-bind check that reads whether the delta receipt exists + beside the work unit, or the work unit carries an explicit exemption line + (`driver-seat: exempt ()`); put one pointer to this URI in the + adopter's boarding text. Three touches, in the adopter's vocabulary. +- **What this does and does not enforce.** A presence gate reads whether the + file exists. It cannot read whether the delta is real. A receipt that says + "looks good" passes the gate and fails the pass; Failure Modes below name + the response. Under the enforcement ladder this is honest L3/L4 territory: + a seat can comply by remembering to write a file, so the gate is a + tripwire, not an enforcer. The interim obligation is the receipt's shape — + a delta with no named change and no named rejection is malformed on its + face, and an inspection may lint for that. --- ## SCOPE — The Governed Surface -- **Runs on:** meals, entrées, catering plates, and every plan revision to - one of those. A revision without a fresh `DELTA.md` is a plan that changed - with no one in the seat. -- **Exempt by default:** fast-food (one-line dishes) and petit fours. The - exemption is written in the ticket, not assumed. -- **Widening is the captain's ruling, not the seat's.** The captain may put - the pass on every plate. The seat does not widen scope on its own and does - not narrow it to save cost. -- **Cost:** one planning-seat turn on a capable model per scoped plate or +- **Runs on:** every work unit above the trivial — anything with a plan of + its own, anything composed of several parts, anything delivered as a set — + and every plan revision to one of those. A revision without a fresh delta + receipt is a plan that changed with no one in the seat. +- **Exempt by default:** the two smallest size classes the adopter defines — + the one-line change, and the small self-contained change. The exemption is + written in the work unit, not assumed. +- **Widening is the operator's ruling, not the seat's.** The operator may + put the pass on every unit. The seat does not widen scope on its own and + does not narrow it to save cost. +- **Cost:** one planning-seat turn on a capable model per scoped unit or revision. Scope stays proportional to that cost, or the rule dies of it. --- +## Example Applications — The Same Step Under Different Metaphors + +These are illustrations, not the binding. A future metaphor supplies its own +row; canon does not change. + +| This method says | Kitchen (`klappy/kitchen`, 2026) | ARS / aviation (v1, retired) | +|---|---|---| +| work unit | ticket / dish | flight / brief | +| scoped classes | meal, entrée, catering plate | mission, multi-leg flight | +| exempt classes | fast-food, petit four | taxi run, single-leg hop | +| planning seat | CoS or expeditor in planning mode | dispatch seat, preflight | +| the step in the lifecycle | `cookbook/tickets/LIFECYCLE.md` step 3, before bind | preflight checklist item, before pushback | +| the presence gate | `cookbook/tickets/CHECKLIST.md` gate 13 "Pass receipt" | a line on the dispatch release | +| delta receipt | `DELTA.md` beside `TICKET.md` | `DELTA.md` in the flight folder | +| boarding pointer | one line in `cookbook/boarding/SHIM.md` | one line in the boarding pass | +| first receipt | kitchen `2026-09-02-door43-mcp-v2-planning` | — | + +--- + ## VERIFICATION — How Compliance Is Proven - A planning seat can `oddkit_get klappy://canon/methods/driver-seat-pass` and observe the prompt verbatim plus when and on what to run it. -- A cook can run the kitchen CHECKLIST on an entrée and observe gate 13 pass - only with a `DELTA.md` present or an explicit exemption line. -- The captain can read this file and find the prompt is his text, unedited. -- A reader can open the folder of the first scoped ticket after it plates - (`klappy/kitchen` `2026-09-02-door43-mcp-v2-planning`) and observe a - `DELTA.md` with named changes and named rejections. -- **Falsifier / retraction condition:** if two consecutive scoped plates - carry `DELTA.md` files that change nothing the challenge would not also - have caught, the pass is not earning its turn — scope narrows by ruling, or - the step retracts and this document is superseded, not deleted. +- An adopter's pre-bind check can be run on a scoped work unit and observed + to pass only with a delta receipt present or an explicit exemption line. +- The operator can read this file and find the prompt is his text, unedited. +- A reader can open the first scoped work unit after it lands and observe a + delta receipt with named changes and named rejections. +- **Falsifier / retraction condition:** if two consecutive scoped units carry + delta receipts that change nothing the challenge would not also have + caught, the pass is not earning its turn — scope narrows by ruling, or the + step retracts and this document is superseded, not deleted. --- @@ -150,23 +179,28 @@ This is a lifecycle step with a file receipt, enforced at the ticket gate: - **Re-read, not a pass:** the seat reads the docs and writes "looks good" — no delta. -- **Scope creep by cost:** the pass runs on fast-food, gets expensive, and - the rule is dropped for everything. -- **Voice edit:** the pass rewrites a captain-voice document because it was +- **Scope creep by cost:** the pass runs on trivial units, gets expensive, + and the rule is dropped for everything. +- **Voice edit:** the pass rewrites an operator-voice document because it was in context. - **Wrong order:** challenge runs first and its findings are made stale by the pass. +- **Metaphor capture:** an adopter's vocabulary is written back into this + method, and the next metaphor cannot inherit it. ## Required Response When Detected -- **Empty delta** → gate 13 fails; the pass is re-run with the docs *and* a - list of every call the seat would make as the user of the system. -- **Cost** → scope stays proportional; the captain widens it by ruling, not +- **Empty delta** → the presence gate fails; the pass is re-run with the + docs *and* a list of every call the seat would make as the user of the + system. +- **Cost** → scope stays proportional; the operator widens it by ruling, not the seat. -- **Voice** → stop; revert the edit; name the proposed change in `DELTA.md` - and show the exact text. +- **Voice** → stop; revert the edit; name the proposed change in the delta + receipt and show the exact text. - **Wrong order** → re-run challenge on the post-pass plan; the earlier run - is noted in DELTA as pre-pass. + is noted in the receipt as pre-pass. +- **Metaphor capture** → move the words to Example Applications; the WHAT, + SCOPE, and ENFORCEMENT sections keep the three neutral terms only. ## See Also @@ -175,8 +209,6 @@ This is a lifecycle step with a file receipt, enforced at the ticket gate: - [Revision Lens Sequence](/canon/methods/revision-lens-sequence.md) — single-lens passes verify; the driver's-seat pass is one such lens - [Borrow Evaluation Before Implementation](/canon/constraints/borrow-evaluation-before-implementation.md) - — the other planning-time table a plan owes before it fires + — the other planning-time table a plan owes before it binds - [Infra Config Is Seat Work](/canon/constraints/infra-config-is-seat-work.md) — the sibling L1 landed the same night, same class of recurring miss -- Kitchen wire: `klappy/kitchen` `cookbook/tickets/LIFECYCLE.md` (step 3), - `cookbook/tickets/CHECKLIST.md` (gate 13) From e01d83238c7a655ac6320290e1e7770012bf334c Mon Sep 17 00:00:00 2001 From: klappy <118073+klappy@users.noreply.github.com> Date: Thu, 3 Sep 2026 04:38:32 +0000 Subject: [PATCH 3/4] =?UTF-8?q?canon(methods):=20rename=20driver-seat-pass?= =?UTF-8?q?=20=E2=86=92=20driver-seat-lens=20(captain:=20'pass'=20is=20ove?= =?UTF-8?q?rloaded;=20picked=20lens,=202026-09-03)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...river-seat-pass.md => driver-seat-lens.md} | 72 +++++++++---------- 1 file changed, 36 insertions(+), 36 deletions(-) rename canon/methods/{driver-seat-pass.md => driver-seat-lens.md} (80%) diff --git a/canon/methods/driver-seat-pass.md b/canon/methods/driver-seat-lens.md similarity index 80% rename from canon/methods/driver-seat-pass.md rename to canon/methods/driver-seat-lens.md index 1984eef2..76af632b 100644 --- a/canon/methods/driver-seat-pass.md +++ b/canon/methods/driver-seat-lens.md @@ -1,13 +1,13 @@ --- -uri: klappy://canon/methods/driver-seat-pass -title: "The Driver's-Seat Pass — A Planning Seat Sits Where the Agent Will Sit Before the Plan Binds" +uri: klappy://canon/methods/driver-seat-lens +title: "The Driver's-Seat Lens — A Planning Seat Sits Where the Agent Will Sit Before the Plan Binds" audience: canon exposure: nav tier: 2 voice: neutral stability: evolving status: draft -tags: ["canon", "methods", "planning", "ergonomics", "agent-legibility", "lifecycle", "receipt", "driver-seat", "metaphor-agnostic"] +tags: ["canon", "methods", "planning", "ergonomics", "agent-legibility", "lifecycle", "receipt", "driver-seat", "lens", "metaphor-agnostic"] epoch: E0010 date: 2026-09-03 derives_from: "canon/bootstrap/model-operating-contract.md, canon/values/axioms.md, canon/constraints/mode-discipline-and-bottleneck-respect.md" @@ -16,23 +16,23 @@ governs: "Any governed body of work, under any operating metaphor: before a plan target_repo: "outcomes-driven-development" --- -# The Driver's-Seat Pass — A Planning Seat Sits Where the Agent Will Sit Before the Plan Binds +# The Driver's-Seat Lens — A Planning Seat Sits Where the Agent Will Sit Before the Plan Binds > Before a plan binds, one planning seat reads the whole design set as the > agent who will have to drive it, and changes the documents until the system -> is legible, coherent, and cheap from that seat. The pass is the constructive -> twin of `oddkit_challenge`: challenge finds what is wrong; the pass finds +> is legible, coherent, and cheap from that seat. The lens is the constructive +> twin of `oddkit_challenge`: challenge finds what is wrong; the lens finds > what is missing. It runs on every unit of work above the trivial, and on > every revision of such a plan; it leaves a delta receipt naming what changed -> and what was considered and rejected. A pass that leaves no delta did not -> run. Operator, 2026-09-02: "that needs to be a policy run on all tickets +> and what was considered and rejected. A lens that leaves no delta was not +> looked through. Operator, 2026-09-02: "that needs to be a policy run on all tickets > and planning loops." --- ## WHAT — The Rule, Precisely -**The prompt.** The pass is the operator's prompt, run verbatim by a planning +**The prompt.** The lens is the operator's prompt, run verbatim by a planning seat with the plan and every design document in context. The text is the operator's and is not edited by any seat (HUMAN-ONLY: voice): @@ -52,29 +52,29 @@ operator's and is not edited by any seat (HUMAN-ONLY: voice): > maximally legible to you as an agent. Really ruminate and meditate on all of > this incredibly deeply before responding or taking any actions. -**The run.** A capable planning seat takes the work unit, its plan, and every +**Looking through it.** A capable planning seat takes the work unit, its plan, and every design document the plan touches into one context and runs the prompt as written, in exploration → planning modes only. No execution. The output is two things: 1. Edits to the design documents themselves, made by the seat. 2. **The delta receipt** — a file stored with the work unit (`DELTA.md` by - convention): for each thing the pass changed, one line naming the change + convention): for each thing the lens changed, one line naming the change and why; for each thing it considered and rejected, one line naming it and the reason; and a picture of the system as one thing, not as a parts list. -**Order.** The pass runs *before* `oddkit_challenge`. The pass finds what is -missing; the challenge then finds what is wrong with the plan the pass left. +**Order.** The lens runs *before* `oddkit_challenge`. The lens finds what is +missing; the challenge then finds what is wrong with the plan the lens left. Running them the other way spends challenge's questions on a plan about to be rewritten. -**Voice.** The pass edits plans and seat-authored documents. A document in the -operator's voice is not edited by the pass; the proposed change is named in -the delta receipt and the pass stops there. +**Voice.** The lens edits plans and seat-authored documents. A document in the +operator's voice is not edited by the lens; the proposed change is named in +the delta receipt and the lens stops there. **Vocabulary.** This method names three things and nothing else: a *work -unit* (the thing being planned), a *planning seat* (whoever runs the pass), -and a *delta receipt* (the file that proves it ran). Every operating +unit* (the thing being planned), a *planning seat* (whoever looks through the lens), +and a *delta receipt* (the file that proves the look happened). Every operating metaphor supplies its own words for the work unit, its size classes, its lanes, and its gates. The method binds to none of them; see Example Applications. @@ -92,7 +92,7 @@ prompt that works once in chat and lives nowhere durable is the rule-in-memory class: it runs when someone remembers it and stops the day they do not. -The pass earns its place because the questions it asks are not the ones the +The lens earns its place because the questions it asks are not the ones the other gates ask. A form check asks whether the fields are there. A challenge asks whether the claims survive pressure. Neither asks the planning seat to sit where the agent will sit and say what would make the job cheap. That is @@ -106,7 +106,7 @@ run every time and not when convenient. This method is a lifecycle step with a file receipt. It is enforced wherever the adopting system already gates a plan before it binds: -- **What canon asks of the adopter.** Name the step in the adopter's own +- **What canon asks of the adopter.** Name the lens as a step in the adopter's own planning lifecycle at the point just before bind; add one gate to the adopter's own pre-bind check that reads whether the delta receipt exists beside the work unit, or the work unit carries an explicit exemption line @@ -114,7 +114,7 @@ the adopting system already gates a plan before it binds: adopter's boarding text. Three touches, in the adopter's vocabulary. - **What this does and does not enforce.** A presence gate reads whether the file exists. It cannot read whether the delta is real. A receipt that says - "looks good" passes the gate and fails the pass; Failure Modes below name + "looks good" passes the gate and fails the lens; Failure Modes below name the response. Under the enforcement ladder this is honest L3/L4 territory: a seat can comply by remembering to write a file, so the gate is a tripwire, not an enforcer. The interim obligation is the receipt's shape — @@ -133,14 +133,14 @@ the adopting system already gates a plan before it binds: the one-line change, and the small self-contained change. The exemption is written in the work unit, not assumed. - **Widening is the operator's ruling, not the seat's.** The operator may - put the pass on every unit. The seat does not widen scope on its own and + put the lens on every unit. The seat does not widen scope on its own and does not narrow it to save cost. - **Cost:** one planning-seat turn on a capable model per scoped unit or revision. Scope stays proportional to that cost, or the rule dies of it. --- -## Example Applications — The Same Step Under Different Metaphors +## Example Applications — The Same Lens Under Different Metaphors These are illustrations, not the binding. A future metaphor supplies its own row; canon does not change. @@ -152,7 +152,7 @@ row; canon does not change. | exempt classes | fast-food, petit four | taxi run, single-leg hop | | planning seat | CoS or expeditor in planning mode | dispatch seat, preflight | | the step in the lifecycle | `cookbook/tickets/LIFECYCLE.md` step 3, before bind | preflight checklist item, before pushback | -| the presence gate | `cookbook/tickets/CHECKLIST.md` gate 13 "Pass receipt" | a line on the dispatch release | +| the presence gate | `cookbook/tickets/CHECKLIST.md` gate 13 "Lens receipt" | a line on the dispatch release | | delta receipt | `DELTA.md` beside `TICKET.md` | `DELTA.md` in the flight folder | | boarding pointer | one line in `cookbook/boarding/SHIM.md` | one line in the boarding pass | | first receipt | kitchen `2026-09-02-door43-mcp-v2-planning` | — | @@ -161,7 +161,7 @@ row; canon does not change. ## VERIFICATION — How Compliance Is Proven -- A planning seat can `oddkit_get klappy://canon/methods/driver-seat-pass` +- A planning seat can `oddkit_get klappy://canon/methods/driver-seat-lens` and observe the prompt verbatim plus when and on what to run it. - An adopter's pre-bind check can be run on a scoped work unit and observed to pass only with a delta receipt present or an explicit exemption line. @@ -170,44 +170,44 @@ row; canon does not change. delta receipt with named changes and named rejections. - **Falsifier / retraction condition:** if two consecutive scoped units carry delta receipts that change nothing the challenge would not also have - caught, the pass is not earning its turn — scope narrows by ruling, or the + caught, the lens is not earning its turn — scope narrows by ruling, or the step retracts and this document is superseded, not deleted. --- -## Failure Modes — What Breaks When the Pass Is a Vibe +## Failure Modes — What Breaks When the Lens Is a Vibe -- **Re-read, not a pass:** the seat reads the docs and writes "looks good" +- **Re-read, not a lens:** the seat reads the docs and writes "looks good" — no delta. -- **Scope creep by cost:** the pass runs on trivial units, gets expensive, +- **Scope creep by cost:** the lens runs on trivial units, gets expensive, and the rule is dropped for everything. -- **Voice edit:** the pass rewrites an operator-voice document because it was +- **Voice edit:** the lens rewrites an operator-voice document because it was in context. - **Wrong order:** challenge runs first and its findings are made stale by - the pass. + the lens. - **Metaphor capture:** an adopter's vocabulary is written back into this method, and the next metaphor cannot inherit it. ## Required Response When Detected -- **Empty delta** → the presence gate fails; the pass is re-run with the +- **Empty delta** → the presence gate fails; the lens is re-run with the docs *and* a list of every call the seat would make as the user of the system. - **Cost** → scope stays proportional; the operator widens it by ruling, not the seat. - **Voice** → stop; revert the edit; name the proposed change in the delta receipt and show the exact text. -- **Wrong order** → re-run challenge on the post-pass plan; the earlier run - is noted in the receipt as pre-pass. +- **Wrong order** → re-run challenge on the post-lens plan; the earlier run + is noted in the receipt as pre-lens. - **Metaphor capture** → move the words to Example Applications; the WHAT, SCOPE, and ENFORCEMENT sections keep the three neutral terms only. ## See Also - [Model Operating Contract](/canon/bootstrap/model-operating-contract.md) — - the four modes; the pass lives at the planning → execution boundary + the four modes; the lens lives at the planning → execution boundary - [Revision Lens Sequence](/canon/methods/revision-lens-sequence.md) — - single-lens passes verify; the driver's-seat pass is one such lens + single-lens passes verify; this is one such lens, given a name and a receipt - [Borrow Evaluation Before Implementation](/canon/constraints/borrow-evaluation-before-implementation.md) — the other planning-time table a plan owes before it binds - [Infra Config Is Seat Work](/canon/constraints/infra-config-is-seat-work.md) From 126d9a4c1016d498bc3fd453fda882bee9447a4e Mon Sep 17 00:00:00 2001 From: klappy <118073+klappy@users.noreply.github.com> Date: Thu, 3 Sep 2026 05:00:24 +0000 Subject: [PATCH 4/4] =?UTF-8?q?canon(methods):=20driver-seat-lens=20?= =?UTF-8?q?=E2=80=94=20receipt=20gate=20is=20the=20pre-execution=20check,?= =?UTF-8?q?=20not=20the=20ordering=20check=20(kitchen#78=20autofix=2069963?= =?UTF-8?q?eb:=20deadlock)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- canon/methods/driver-seat-lens.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/canon/methods/driver-seat-lens.md b/canon/methods/driver-seat-lens.md index 76af632b..84039b21 100644 --- a/canon/methods/driver-seat-lens.md +++ b/canon/methods/driver-seat-lens.md @@ -108,7 +108,9 @@ the adopting system already gates a plan before it binds: - **What canon asks of the adopter.** Name the lens as a step in the adopter's own planning lifecycle at the point just before bind; add one gate to the - adopter's own pre-bind check that reads whether the delta receipt exists + adopter's own pre-execution check (the last gate before work starts, after + the planning seat has had its turn — not the ordering check, which runs + before the lens and would deadlock) that reads whether the delta receipt exists beside the work unit, or the work unit carries an explicit exemption line (`driver-seat: exempt ()`); put one pointer to this URI in the adopter's boarding text. Three touches, in the adopter's vocabulary. @@ -152,7 +154,7 @@ row; canon does not change. | exempt classes | fast-food, petit four | taxi run, single-leg hop | | planning seat | CoS or expeditor in planning mode | dispatch seat, preflight | | the step in the lifecycle | `cookbook/tickets/LIFECYCLE.md` step 3, before bind | preflight checklist item, before pushback | -| the presence gate | `cookbook/tickets/CHECKLIST.md` gate 13 "Lens receipt" | a line on the dispatch release | +| the presence gate | `cookbook/tickets/FIRE-CHECK.md` gate 8 "Lens receipt" (CHECKLIST gate 13 only checks the exemption line for exempt classes) | a line on the dispatch release | | delta receipt | `DELTA.md` beside `TICKET.md` | `DELTA.md` in the flight folder | | boarding pointer | one line in `cookbook/boarding/SHIM.md` | one line in the boarding pass | | first receipt | kitchen `2026-09-02-door43-mcp-v2-planning` | — | @@ -163,8 +165,9 @@ row; canon does not change. - A planning seat can `oddkit_get klappy://canon/methods/driver-seat-lens` and observe the prompt verbatim plus when and on what to run it. -- An adopter's pre-bind check can be run on a scoped work unit and observed - to pass only with a delta receipt present or an explicit exemption line. +- An adopter's pre-execution check can be run on a scoped work unit and + observed to pass only with a delta receipt present or an explicit + exemption line. - The operator can read this file and find the prompt is his text, unedited. - A reader can open the first scoped work unit after it lands and observe a delta receipt with named changes and named rejections.