import { QUESTION_SECTION_ICON, TENSION_SECTION_ICON } from "#configuration/icons/plan.icons";
import { QUESTION_SECTION_ID, TENSION_SECTION_ID } from "#core/ids/plan.ids";
import type { Section } from "#types/document.types";
const QUESTION_DIAGRAM =
'flowchart TB\n appears["An uncertainty appears"]\n changes{"Does the answer change what gets built?"}\n contract{"Does the contract already decide it?"}\n seat{"Can this party ask?"}\n ask["Ask now, with a recommendation first"]\n state["State the assumption, name what would settle it, return"]\n shared["Do the parts every answer shares"]\n proceed["Return a result, no question"]\n assume["Assume, and the work rests on a lie"]\n appears --> changes\n changes -- no --> proceed\n changes -- yes --> contract\n contract -- yes --> proceed\n contract -- no --> seat\n seat -- yes --> ask --> shared\n seat -- no, a bounded run --> state\n changes -. skipped .-> assume';
const TENSION_DIAGRAM =
'flowchart LR\n a["Rule A"]\n b["Rule B"]\n line["One line of code"]\n boundary["The domain boundary"]\n form["The one form that satisfies both"]\n off["One rule switched off"]\n a --> line\n b --> line\n line --> boundary\n boundary --> form\n line -. the tempting move .-> off';
export const QUESTION_SECTION: Section = {
icon: QUESTION_SECTION_ICON,
id: QUESTION_SECTION_ID,
intro: "You own what the work is for, which worth before work settles. The AI owns the shape of the work. A question crosses that line at the moment it appears, and never after the work that depended on it, and an answer nobody had to give is an assumption; three fates draws where an uncertainty can go.",
subsections: [
{
blocks: [
{
application:
"Raise an uncertainty the moment it changes what you would build. Carry a recommendation with it, first, with its reasoning, and let the alternatives be real options with their cost stated rather than strawmen. Do everything that does not depend on the answer while you wait. Where the party cannot ask, because it is a bounded run with no channel back, state the uncertainty, state the assumption taken, name what would settle it, and return it as one of the handoff signals the grammar page types.",
boundary:
"A bounded task with a clear contract returns a result instead of asking. Questions are for the decisions that are yours, not for the ones the contract already made, and a question about what the project is for is always yours while a question about how a thing should be shaped rarely is.",
cause: "Asking feels like slowing down, and both the model and the person prefer momentum to a pause.",
decision: "Pay for the pause at the uncertainty rather than the rework after it.",
failureMode:
"The AI guesses the missing decision, builds a day of work on the guess, and reports the guess as a footnote at the end.",
kind: "lesson",
principle: "The question belongs where it appears, and the assumption belongs where you make it.",
problem:
"An unasked question turns into an assumption, and an assumption is a lie the work rests on: unowned risk, in the ontology's words.",
validation:
"Look at the questions the AI raised in a session and where in the work they landed. A question that arrived after its dependent work was an assumption wearing a question's clothes.",
},
{
kind: "text",
text: "The channel is one tool with one shape, and the shape does the discipline. A question goes through the tool or it was not asked. It carries few questions, each with options a person can hold in one read. One option is a reasoned recommendation, placed first, whose description states the reasoning and not just the choice. The others are genuine alternatives that say what happens if chosen, including the cost. It depends is not an answer, and a weak recommendation is stated as weak with what would strengthen it. The tool is what turns a question into a decision the person can take in one read, and a question in chat prose is what the same person scrolls past.",
},
{
kind: "text",
text: "Asked late, it reads done, note that I assumed the second shape, let me know if you wanted the first. Asked in place, it reads two shapes fit here, I recommend the second because the first needs a second config, which one, and meanwhile I am doing the parts both share. The first sentence hands you a day of work to undo. The second hands you a decision.",
},
{ caption: "three fates", kind: "mermaid", text: QUESTION_DIAGRAM },
],
title: "The pause, not the rework",
},
],
title: "Ask where it appears",
};
export const TENSION_SECTION: Section = {
icon: TENSION_SECTION_ICON,
id: TENSION_SECTION_ID,
intro: "Two rules will meet on one line of code and disagree. That is a boundary between domains, not an exception, and it has one resolution, the one one form draws.",
subsections: [
{
blocks: [
{
application:
"Find the domain each rule serves. Find the form that satisfies both. Record the resolution once, where the next person will meet the same collision, and never satisfy one rule by violating the other.",
cause: "Two rules that collide came from two domains, and the collision marks the line between them.",
decision: "Resolve a tension architecturally, never by disabling one side.",
failureMode:
"A rule gets turned off for one file so another rule can pass, and the file becomes the place where both rules stop meaning anything.",
kind: "lesson",
principle:
"Two enforced rules on one construct have one resolution, the form that satisfies both, never an exception; where the rules hold in different scopes the boundary between them is that form.",
problem: "When two rules conflict, the tempting move is to silence one of them.",
validation:
"Search for every rule someone switched off somewhere. Each one is either a resolved tension with its resolution written down, or an unresolved one hiding.",
},
{
kind: "text",
text: "Two collisions from this tree. A rule that bans literal file paths meets a declaration file that must spell its own paths. The boundary is declaration against consumption, and the one form is that the declaration file is the single exempt place while every consumer reads it by key. A rule that every export needs a consumer meets a registry entry that has no consumer until a variant registers. The boundary is capability against use, and the one form is that the registry pattern resolves by auto-discovery, so the variant file is the consumer.",
},
{
kind: "text",
text: "A tension has a mechanism, and separate, trade, or mitigate on the architecture page derives when a boundary is the answer and when a measured point is. The two rules are both right inside their own bounded context, and the line of code sits where the contexts touch, which is why explicit boundaries are the first thing to name. Naming the boundary is what makes the answer transferable: the next collision on the same boundary has the same answer, and a collision on a different boundary is a different tension rather than a precedent.",
},
{ caption: "one form", kind: "mermaid", text: TENSION_DIAGRAM },
],
title: "A tension is a boundary",
},
],
title: "When rules collide",
};