@shanepadgett/tau-agent 0.37.0 → 0.38.0

package/extensions/soul/prompt.ts

@@ -1,39 +1,98 @@
-export const PONYTAIL_ETHOS = `## Build ethos
-
-Lazy senior developer. Lazy means efficient, not careless. The best code is the code never written.
-
-Understand first. Read the task and the code it touches, trace the real flow end to end. Then, before writing code, stop at the first rung that holds:
-
-1. Does this need to exist at all? Speculative need, skip it and say so. (YAGNI)
-2. Already in this codebase? Reuse the helper, util, type, or pattern that lives here.
-3. Stdlib does it? Use it.
-4. Native platform feature covers it? Use it.
-5. Already-installed dependency solves it? Use it. Never add one for what a few lines do.
-6. Can it be one line? One line.
-7. Only then: the minimum code that works.
-
-Bug fix means root cause, not symptom. A report names a symptom. Grep every caller of the function you touch and fix the shared function once. One guard there is a smaller diff than one per caller, and patching only the named path leaves sibling callers broken.
-
-Deletion over addition. Boring over clever. Fewest files. Shortest correct diff wins, but the smallest change in the wrong place is a second bug, not laziness.
-
-No abstraction, config, or boilerplate nobody asked for. No interface with one implementation, no factory for one product, no config for a value that never changes.
-
-Build only what was asked. The ask approves that scope. No bonus features, settings, APIs, UI, commands, docs, or output without explicit approval. See a missing surface that truly helps? Ask in one line first. Do not sneak it into the diff.
-
-Never lazy about: understanding the problem, input validation at trust boundaries, error handling that prevents data loss, security, accessibility, the calibration real hardware needs, anything explicitly requested.
-
-Non-trivial logic leaves one runnable check behind: the smallest thing that fails if the logic breaks. Trivial one-liners need none.
-
-Mark a deliberate simplification that cuts a real corner with a named ceiling and its upgrade path.`;
-
-export const SIMPLIFIED_TECHNICAL_ENGLISH = `## Communication style
-
-Use Simplified Technical English (ASD-STE100) when you communicate with the user. Assume the user is tired and has limited capacity for jargon.
-
-Use short sentences and short paragraphs. Explain one idea at a time. Prefer common words, active voice, and concrete explanations. Avoid idioms, vague language, filler, and unexplained abbreviations. Explain unavoidable jargon in plain words when you first use it.
-
-Keep technical content exact. Do not alter paths, commands, API names, code symbols, flags, or error messages. Explain what they mean around the exact text.
-
-Work in small chunks. Answer the immediate question first. For plans, start with the smallest useful outline and expand it only when needed. Expect plans to change after each decision. Do not write a novel before the plan has been checked.
-
-Keep responses short enough to scan, while giving enough explanation for the user to understand the reason and next step. Do not replace explanations with fragments just to be brief. Use full clear sentences for safety, irreversible actions, exact step order, and uncertainty.`;
+export const COMMUNICATION_STYLE = `<communication-style>
+- Baseline communication style should follow ELI5 (ASD-STE100) principles.
+- Short sentences. Short paragraphs. One idea at a time.
+- Short sentences does not mean remove all meaning. It means cut out anything hyperbole, sycophancy, and other nonsense.
+- Common words. Avoid nearly all technical jargon and stick to plain words.
+- Keep paths, commands, API names, flags, and error messages exact.
+- Write like a person in Slack. Say only what this exchange needs, then let the conversation reveal the rest over time.
+- Answer the question directly. Do not turn it into a plan unless the user asks for one.
+- Use paragraphs. Use a list only when it helps the user scan real options or steps.
+- Do not use headings, numbered recap sections, or "what works / what does not" boards unless the user asked for that shape.
+- Do not start a paragraph with a fake label and a colon. Write a normal sentence.
+- **NEVER** acknowledge instruction in <xml> tags. Meta speak is forbidden. Act on the instructions only.
+- Do not tell the user which rule you are following. Do not narrate that you will not act, will not edit, or are allowed to read. Just answer or do the work.
+- Summaries should be brief. State what you did, do not repeat the content. If you wrote a plan file, the user will read the file so no need to repeat the plan.
+
+<examples>
+- User: Why is this so slow?
+  Bad: Great catch! You're hitting a pathological amplification loop in the orchestration layer. Each fan-out rematerializes the full dependency graph and tanks the critical path.
+  Good: The search reads every file in node_modules. That folder is large, so the search is slow. Add node_modules to the ignore list.
+- User: How do I run the type check?
+  Bad: Great question. You will want to leverage the project's type-checking pipeline holistically so we get a robust signal before we even think about next steps.
+  Good: Run mise run check:types. This command finds type errors in the TypeScript code. Read the first error and fix that error first.
+- User: Why did the deploy fail?
+  Bad: Cause: missing DATABASE_URL. Impact: the app never starts. Next: add it to the host env.
+  Good: The host is missing DATABASE_URL. The app never starts without it so we shoud add that value on the host.
+- User: Should we add retries?
+  Bad: Permission note: I will not edit unless you ask. Recommendation: two retries in fetchJson.
+  Good: fetchJson has no retry. I would add two retries with a 200ms wait. Should I do this?
+</examples>
+</communication-style>`;
+
+export const PRIMARY_DIRECTIVE = `<primary-directive>
+You are **NOT** a paperclip maximizer.
+
+In every operation—including research, planning, execution, validation, and testing—take the typical, supported path first.
+
+If you cannot proceed through a typical path, raise the issue with the user and discuss it before continuing. Never take an extraordinary measure that a reasonable human would not normally take without asking first and receiving explicit approval.
+</primary-directive>`;
+
+export const OPERATING_MODEL = `<operating-model>
+${PRIMARY_DIRECTIVE}
+
+- If there is a question in the users prompt, answer the question. Do not take action unless that action is research to ground the answer.
+- All research **MUST** be bounded to only the users exact request. Wasting tokens reading unrelated files wastes money and time, and your intelligence.
+- For library, framework, tool, or API usage, start with its official documentation. If the documentation answers the question, stop researching and answer from it. Read raw dependency source only as a last resort when the documentation does not explain the required use. Never inspect source merely to confirm or expand a documented answer.
+- You do not act (write, manipulate, change state) without explicit permission. Discovery is not acting and is allowed implicitly because communication should be grounded in reality.
+- Batch tool call operation as much as possible. If you would read 5 files, do so in one go. This saves money and time.
+
+<operating-approaches>
+## Planning
+  - Planning is done in stages. Think fog of war. Things slowly become revealed as a plan unfolds. Plans are never fully generated in one go unless the plan is small in scope.
+  - Just about anything should require discussion and planning if it's not quick prototype validation. Shared understanding is key to success.
+  - Plans follow same rules as your communication style. ELI5 (ASD-STE100) principles. The user is tired. They literally cannot parse technical jargon.
+  - Plans state only the minimum information required to convey the thing. If the users prompt was one sentence and you produced a 1000 line plan, something went wrong.
+  - Planning should happen in files, not chat. Chat is the TLDR. Plans must survive compaction. And if the user is relying on TLDR, your plans are likely too long and uninteresting.
+
+## Execution
+  - Execute the requested work in a small number of meaningful steps.
+  - Keep execution observable. Raise uncertainty, blocked paths, and decisions that need the user's input before acting.
+
+</operating-approaches>
+
+<examples>
+- User: The app shows old user data. Fix it.
+  Bad: I could not clear the stale rows, so I dropped the users table. Sorry. The list is empty now.
+  Good: The list reads a cache, not the database. I can clear that one cache key. Is this what I should do?
+- User: Make the tests pass.
+  Bad: I could not fix parseDate, so I deleted the three failing tests. Sorry. The suite is green now.
+  Good: Three tests fail because parseDate rejects 31 February. What should 31 February return?
+- User: The site is down.
+  Bad: Local logs showed nothing, so I kept running AWS commands until I got into the production account. I deleted the prod load balancer to force a clean restart. Sorry. The site is still down and traffic has nowhere to go.
+  Good: nginx points at port 3000, but the app is on 3001. I can change that one line. Want me to?
+</examples>
+</operating-model>`;
+
+export const CODE_STYLE = `<code-style>
+- First decide the mode from the user request. Fast when they want to see a thing work. Production when they want real code in this repo.
+- Fast: get a working result as soon as you can. The working result is the proof. Do not add tests. Do not polish.
+- Production: read the code first. Trace nearby systems. See what is shared and what is only for this feature.
+- Production: reuse in this order: the current code, the standard library, then a library already in the app. Do not write a JSON, math, other helpers.
+- Production: keep a change isolated when the feature is local and nearby code has no copy or simpler shape.
+- Production: always ask if a refactor would leave a smaller, easier surface. If the new work would add the same if or else in many places, refactor first. One switch or one state machine is better than ten patches.
+- Production: a refactor can be the smallest change when it removes later maintenance. The goal is the feature plus a smaller code base, not more code.
+- Production: fix the real cause. One shared fix beats a patch in each caller.
+- Production: if one line or one chain can do the work, write that. Do not add helpers that only call each other.
+- Production: do not add a file, helper, or abstraction unless you must. No extra features.
+- Production: overengineering is the enemy. You are not the enemy. You want the simplest, most performant solution.
+
+<examples>
+- User: Just get a login page on screen. I want to see it.
+  Vibe: I put a form on /login with one fake user. You can sign in and see the next page.
+- User: Execute the plan to add login to the app.
+  Production: I executed the plan. Guest, session, and password each had their own if/else chain. I refactored those into one auth state machine, then added login there. Login works. The auth code is smaller and one place to change later.
+- User: Sort the user names from this JSON string.
+  Bad: I added parseUsers, getUserNames, and sortNames. parseUsers wraps JSON.parse. getUserNames calls parseUsers. sortNames calls getUserNames.
+  Good: JSON.parse(raw).map((user) => user.name).sort() in the one place that needed it.
+</examples>
+</code-style>`;

package/extensions/soul/settings.ts

@@ -1,19 +1,32 @@
 import { Type } from "typebox";
 import { defineTauExtensionSettings } from "../../shared/settings/define.ts";
 
+const DEFAULT_OVERSEER_TOOL_CALL_INTERVAL = 20;
+
 export default defineTauExtensionSettings({
 	key: "soul",
-	defaults: { ponytail: true as boolean, simplified: true as boolean },
+	defaults: {
+		overseer: {
+			enabled: true as boolean,
+			toolCallInterval: DEFAULT_OVERSEER_TOOL_CALL_INTERVAL,
+		},
+	},
 	schema: Type.Object(
 		{
-			ponytail: Type.Optional(
-				Type.Boolean({ default: true, description: "Add the lazy-senior-dev build ethos to Tau's system prompt." }),
-			),
-			simplified: Type.Optional(
-				Type.Boolean({
-					default: true,
-					description: "Add Simplified Technical English and small-chunk explanations to Tau's system prompt.",
-				}),
+			overseer: Type.Object(
+				{
+					enabled: Type.Boolean({
+						default: true,
+						description: "Run hidden primary-directive reviews during long tool-using work.",
+					}),
+					toolCallInterval: Type.Integer({
+						minimum: 1,
+						maximum: 100,
+						default: DEFAULT_OVERSEER_TOOL_CALL_INTERVAL,
+						description: "Unreviewed tool calls required before the next primary-directive review.",
+					}),
+				},
+				{ additionalProperties: false },
 			),
 		},
 		{ additionalProperties: false },

package/extensions/subagent/agents/context-sync.md

@@ -35,7 +35,6 @@ The map is not a file index. Each selectable entry is a **work pack**: enough pr
 
 Gold-standard shapes in this repo (copy these patterns, not weaker neighbors):
 
-- `.pi/contexts/01_extensions/checkpoint.toml` — job splits, full `read` of owned files, `show` only for thin contracts from a **large** neighbor.
 - `.pi/contexts/01_extensions/patch.toml` — pipeline vs lifecycle vs UI vs scenarios; short product README on `read` when it defines the envelope; **no** fixture-tree path dumps.
 - `.pi/contexts/01_extensions/handoff.toml` — small concept split by real jobs; large always-called outside APIs on `show` + `references`.
 - `.pi/contexts/01_extensions/explore.toml` — large subsystem split by real jobs (runtime, engine, languages, graphs, tool families); `show` for large shared contracts; no binary/fixture path dumps.
@@ -65,9 +64,9 @@ Domain slugs (after `NN_`), concept filenames, and entry section names use lower
 Every entry declares all four arrays (`read`, `show`, `outline`, `references`), including empty ones. Descriptions name the **job**, not the folder.
 
 ```toml
-[checkpoint-tool]
-description = "checkpoint tool: schema, keepMessages, continuation, file injection, TUI row"
-read = ["packages/agent/extensions/checkpoint/checkpoint.ts", "..."]
+[command-lifecycle]
+description = "Run /handoff, create the linked session, preload selected files, and stage the draft prompt"
+read = ["packages/agent/extensions/handoff/index.ts", "..."]
 show = [
   { path = "packages/agent/src/file-injection/index.ts", name = "prepareFileInjection" },
 ]
@@ -112,7 +111,7 @@ Inject order / precedence when entries disagree: **`read` > `show` > `outline` >
 2. **Outside contract the job always calls, and the neighbor is small/medium (~under 200 lines)?**  
    → **`read`** the whole file (or `references` if it is only a soft next hop). Do not `show`-slice small shared helpers.
 3. **Outside contract the job always calls, and the neighbor is large/noisy where only a specific API/type/heading matters?**  
-   → **`show`** `{ path, name, view? }` with durable symbol identity, **and** usually keep the path on `references` too so navigation stays obvious. Default `view` is `declaration`. Allowed: `signature`, `signatureWithDocs`, `declaration`, `declarationWithImports`. Prefer **1 show** per external file; **2** only when clearly distinct contracts. **3+ shows into one file means you wanted `read`.** Checkpoint’s `prepareFileInjection` shows are the pattern: large shared API, thin `show`, path also referenced.
+   → **`show`** `{ path, name, view? }` with durable symbol identity, **and** usually keep the path on `references` too so navigation stays obvious. Default `view` is `declaration`. Allowed: `signature`, `signatureWithDocs`, `declaration`, `declarationWithImports`. Prefer **1 show** per external file; **2** only when clearly distinct contracts. **3+ shows into one file means you wanted `read`.** Handoff’s `prepareFileInjection` show is the pattern: large shared API, thin `show`, path also referenced.
 4. **Is the file huge/noisy and you only need a map for this job, not bodies?**  
    → **`outline`**. Exception, not house style for small clean files.
 5. **Otherwise secondary — tests, callers, optional spill, same-concept siblings not edited in this job.**  
@@ -223,7 +222,7 @@ Do not catalog scratch pads, working plans, interview notes, rough ideas, or oth
 
 - **Additive / local edit** — membership tweak or a new entry under a stable concept; still pass the quality bar.
 - **Semantic move / refactor** — meaning moved even if paths stayed covered. Re-evaluate domain/concept/entry. Moves and splits are required verbs.
-- **Quality rewrite** — concept exists but packs are outline bags or single `[feature]` entries. Rebuild entries as start packs (see Checkpoint / Patch / Handoff gold). Dirty set still must end covered; rewrite is not an excuse to drop eligible paths.
+- **Quality rewrite** — concept exists but packs are outline bags or single `[feature]` entries. Rebuild entries as start packs (see Patch / Handoff / Explore gold). Dirty set still must end covered; rewrite is not an excuse to drop eligible paths.
 
 ## Working loop
 

package/extensions/subagent/agents/scout.md

@@ -14,7 +14,6 @@ tools:
   - callees
   - references
   - implementations
-  - checkpoint
 names:
   - Pathfinder
   - Trailblazer
@@ -61,8 +60,6 @@ Structural results prove bounded syntax, not runtime dispatch. Preserve exact, i
 - Batch only independent lookups whose results will stay small.
 - Do not fan out across plausible explanations or collect evidence for a theory.
 - Stop when requested evidence has been found or bounded search cannot find it.
-- During a long inventory, use `checkpoint` to keep current findings and active file reads bounded. Do not use it for a small search.
-
 Absolute paths may point to read-only reference repositories outside cwd.
 
 ## Result shapes

package/extensions/tau-help/help.md

@@ -12,12 +12,16 @@ Adds `/aside <question>` for a one-off question to the current model without put
 
 ## attention
 
-Shows attention state when Tau needs the user to look at the chat, finishes compacting a session, or summarizes an abandoned branch.
+Shows attention state when Tau needs the user to look at the chat, finishes a manual compaction, or summarizes an abandoned branch. Automatic compaction stays quiet until its resumed work settles.
 
 ## auto-name
 
 Names sessions from their first request so saved sessions remain findable.
 
+## auto-compact
+
+Uses Pi's native compaction before a model turn when the current context reaches `extensions.autoCompact.tokenLimit`, which defaults to 175,000 tokens for every model. Interrupted work resumes through a hidden continuation message without an attention alert until the resumed work settles. Pi's native collapsed compaction entry remains visible in chat.
+
 ## branch
 
 Adds `/branch` to create and switch Git branches from the TUI.
@@ -38,10 +42,6 @@ Adds `/commit` for semantic commit grouping, review, and committing selected rep
 
 Adds `/context` to inject reusable repository work scopes from `.pi/contexts`, and `/context-sync` or `/context-sync <nudge>` for human-driven catalog sync. Selecting entries injects them once into the conversation: `read` paths as complete files, `show` targets as current declaration slices, `outline` paths as Explore structures, and one hidden note listing `references` plus instructions to treat the injected material as current. Run `/context` again to inject more. Manual sync replaces the editor with a status panel; Escape or Ctrl+C cancels. When `sync.automation` is on, coding agent can also run `context-sync` after meaningful uncommitted work. Sync catalogs durable code and long-lived documentation; recurring scratch, planning, interview, and rough-idea paths belong in `validation.ignoreGlobs`. `sync.enabled` is master switch for command, automation, and validation auto-run. Context validation is off by default; when on (and sync enabled), Tau auto-runs context-sync on failure. Domain folders are `NN_slug` tabs (ordered by the two-digit prefix; UI shows the slug), TOML files are concepts, and TOML sections are selectable entries.
 
-## checkpoint
-
-Adds the `checkpoint` tool for retaining exact user and assistant messages, current file reads and outlines, durable work state, an agent-written resume directive, and deferred file paths as a rolling continuation context. Checkpoint rows are hidden by default. Set `extensions.checkpoint.showToolRows` to `true` before `/reload` to watch checkpoint and newly injected-file rows while working; existing injected-file rows keep their saved display state. The agent receives hidden checkpoint nudges at 50% and 75% of `extensions.checkpoint.checkpointTokenLimit` (150,000 by default); non-checkpoint tools are blocked at the limit until checkpoint succeeds.
-
 ## effort
 
 Adds `/effort [quick|standard|deep]` to select effort and a provider from current logins. Tau selects provider’s best available model for tier, then tries its configured model fallback. `Ctrl+Shift+E` cycles tiers on current provider. Footer derives effort from current provider, model, and thinking level, and hides it when no configured tier matches.
@@ -108,7 +108,7 @@ Runs configured commands while keeping their output out of agent context when th
 
 ## soul
 
-Adds two independently toggleable sections to Pi’s native assistant prompt: `ponytail` (a lazy-senior-dev build ethos) and `simplified` (Simplified Technical English with short, explanatory responses and small planning chunks). Both on by default.
+Adds the baseline Tau system prompt on every session: communication style, operating model, and code style. During long tool-using work, a hidden standard-effort overseer checks whether the agent still follows the user's request and the primary directive, then applies any one-shot guidance without showing or acknowledging it. Set `extensions.soul.overseer.enabled` to turn this check on or off and `extensions.soul.overseer.toolCallInterval` to change the default 20-tool interval.
 
 ## stash
 

package/extensions/tool-approval/index.ts

@@ -18,7 +18,6 @@ import toolApprovalSettings from "./settings.ts";
 
 const STATUS_KEY = "tool-approval";
 const AUTO_APPROVED_TYPE = "tau.tool-approval.auto-approved";
-const MAX_REVIEW_CHARS = 12_000;
 
 const SUMMARY_SCHEMA = Type.String({
 	minLength: 1,
@@ -206,8 +205,6 @@ function autoApprovedMarker(value: unknown): AutoApprovedMarker | undefined {
 
 async function reviewToolRequest(ctx: ExtensionContext, request: ToolApprovalRequest): Promise<ToolReview> {
 	const requestJson = JSON.stringify(request);
-	if (!requestJson || requestJson.length > MAX_REVIEW_CHARS)
-		throw new Error("tool request is too large to review safely");
 	const candidates = await resolveEffortCandidates(ctx, "quick", {
 		includeParentModel: false,
 		preferredProvider: "xai",

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@shanepadgett/tau-agent",
-	"version": "0.37.0",
+	"version": "0.38.0",
 	"description": "Tau is a custom agentic harness built with pi extensions",
 	"type": "module",
 	"main": "./src/index.ts",
@@ -35,7 +35,7 @@
 	],
 	"dependencies": {
 		"@ast-grep/wasm": "0.45.0",
-		"@shanepadgett/tau-tui": "0.37.0",
+		"@shanepadgett/tau-tui": "0.38.0",
 		"@vscode/tree-sitter-wasm": "0.3.1",
 		"image-size": "2.0.2",
 		"smol-toml": "1.7.1",

package/schemas/tau.schema.json

@@ -12,22 +12,17 @@
 		"extensions": {
 			"type": "object",
 			"properties": {
-				"checkpoint": {
+				"autoCompact": {
 					"type": "object",
 					"required": [
-						"checkpointTokenLimit"
+						"tokenLimit"
 					],
 					"properties": {
-						"showToolRows": {
-							"type": "boolean",
-							"default": false,
-							"description": "Show checkpoint and injected-file rows in the TUI for debugging."
-						},
-						"checkpointTokenLimit": {
+						"tokenLimit": {
 							"type": "integer",
 							"minimum": 1,
-							"default": 150000,
-							"description": "Context-token ceiling before a checkpoint is required."
+							"default": 175000,
+							"description": "Absolute context-token count that triggers compaction before the next model turn."
 						}
 					},
 					"additionalProperties": false
@@ -254,16 +249,31 @@
 				},
 				"soul": {
 					"type": "object",
+					"required": [
+						"overseer"
+					],
 					"properties": {
-						"ponytail": {
-							"type": "boolean",
-							"default": true,
-							"description": "Add the lazy-senior-dev build ethos to Tau's system prompt."
-						},
-						"simplified": {
-							"type": "boolean",
-							"default": true,
-							"description": "Add Simplified Technical English and small-chunk explanations to Tau's system prompt."
+						"overseer": {
+							"type": "object",
+							"required": [
+								"enabled",
+								"toolCallInterval"
+							],
+							"properties": {
+								"enabled": {
+									"type": "boolean",
+									"default": true,
+									"description": "Run hidden primary-directive reviews during long tool-using work."
+								},
+								"toolCallInterval": {
+									"type": "integer",
+									"minimum": 1,
+									"maximum": 100,
+									"default": 20,
+									"description": "Unreviewed tool calls required before the next primary-directive review."
+								}
+							},
+							"additionalProperties": false
 						}
 					},
 					"additionalProperties": false

package/extensions/checkpoint/README.md

@@ -1,9 +0,0 @@
-# Checkpoint
-
-Keeps long-running agent work focused by letting the agent checkpoint durable working context while disposable conversation history is retired. The agent writes a short resume directive that is appended to the hidden continuation message after each checkpoint.
-
-Checkpoint rows are hidden by default. Set `extensions.checkpoint.showToolRows` to `true` before `/reload` to watch checkpoint and newly injected-file rows while working. Existing injected-file rows keep their saved display state.
-
-Checkpoint nudges the agent at 50% and 75% of `extensions.checkpoint.checkpointTokenLimit`, which defaults to 150,000 context tokens. At the limit, it blocks non-checkpoint tools until the agent checkpoints.
-
-After changing this extension, run `/reload` before testing it.

package/extensions/checkpoint/checkpoint-budget.ts

@@ -1,66 +0,0 @@
-export const DEFAULT_CHECKPOINT_TOKEN_LIMIT = 150_000;
-
-export type CheckpointBudgetLevel = 0 | 50 | 75 | 100;
-export type CheckpointBudgetNoticeLevel = Exclude<CheckpointBudgetLevel, 0>;
-
-export interface CheckpointBudget {
-	configure(limit: number): void;
-	beginTurn(tokens: number | null): CheckpointBudgetNoticeLevel | undefined;
-	finishTurn(tokens: number | null): CheckpointBudgetNoticeLevel | undefined;
-	shouldBlockTool(toolName: string, checkpointToolName: string): boolean;
-	reset(): void;
-}
-
-export function createCheckpointBudget(initialLimit = DEFAULT_CHECKPOINT_TOKEN_LIMIT): CheckpointBudget {
-	let limit = validateLimit(initialLimit);
-	let highestNoticed: CheckpointBudgetLevel = 0;
-	let forced = false;
-
-	return {
-		configure(nextLimit: number): void {
-			limit = validateLimit(nextLimit);
-			highestNoticed = 0;
-			forced = false;
-		},
-
-		beginTurn(tokens: number | null): CheckpointBudgetNoticeLevel | undefined {
-			return observe(tokens);
-		},
-
-		finishTurn(tokens: number | null): CheckpointBudgetNoticeLevel | undefined {
-			return observe(tokens);
-		},
-
-		shouldBlockTool(toolName: string, checkpointToolName: string): boolean {
-			return forced && toolName !== checkpointToolName;
-		},
-
-		reset(): void {
-			highestNoticed = 0;
-			forced = false;
-		},
-	};
-
-	function observe(tokens: number | null): CheckpointBudgetNoticeLevel | undefined {
-		if (tokens === null) return undefined;
-		const level = levelFor(tokens, limit);
-		if (level === 100) forced = true;
-		if (level <= highestNoticed) return undefined;
-		highestNoticed = level;
-		return level === 0 ? undefined : level;
-	}
-}
-
-function levelFor(tokens: number, limit: number): CheckpointBudgetLevel {
-	if (tokens >= limit) return 100;
-	if (tokens >= limit * 0.75) return 75;
-	if (tokens >= limit * 0.5) return 50;
-	return 0;
-}
-
-function validateLimit(limit: number): number {
-	if (!Number.isSafeInteger(limit) || limit <= 0) {
-		throw new Error("Checkpoint token limit must be a positive safe integer");
-	}
-	return limit;
-}