Oh My Pi Workbook

A complete practical guide to OMP sessions, memory, tangent subagents, tool permissions, and extensions, with fictional labs, intact examples, and explicit evidence boundaries.

One complete reading sequence across session continuity, memory, tangent subagents, tool permissions and approvals, and extensions. Original chapters, examples and evidence boundaries remain intact.

Start reading: Begin with the shared scope and follow the complete book in order.
Choose a reading path: Follow the chapters that address the work you need to do.
Follow the recorded examples: Explore the supplied permission, extension and continuity milestones, with their evidence limits.
Take the source with you: Download the complete example bundle. Nothing on this page runs it.

The complete book

Open a part to see its chapters. Every chapter has its own Markdown edition and previous/next navigation; nothing is omitted when a group is closed.

Start here 1

A complete practical guide to OMP sessions, memory, tangent subagents, tool permissions, and extensions, with fictional labs, intact examples, and explicit evidence boundaries.

Start here

Sessions, resets, and reviewable history 19

Choose the intended conversation, change only the intended session boundary, and inspect the full representation before considering disclosure.

Memory and reusable knowledge 14

Distinguish current context from retained evidence and reusable procedures, then inspect scope and outcomes instead of trusting memory acknowledgements.

Tangent work and live control 17

Find the exact tangent, address its current conversation, and separate view changes, turn interruption, job cancellation, revival, and terminal intent.

Tool permissions and approvals 15

Explain why a particular tool call is allowed, prompted, or denied by following its operation, tier, policy identity, host capabilities, and actual effect boundary.

Extensions inside those boundaries 23

Build explicit human and machine capabilities whose permissions, state lifetimes, delivery, loading, and verification match the host that actually runs them.

Connections and next steps 8

Connect the boundaries, resolve shared terminology, and choose a safe next step.

Choose your reading path

These editorial routes link into the complete book. Follow the listed order, or use the part navigation to read around a topic.

Return to a known conversation without restoring old files

Use this route when a history is missing, the newest conversation is the wrong one, or a project directory has moved; establish identity and scope before adding work.

Understand why an old fact returns after a reset

Separate retained history, cached injection, scoped memory, and reusable skills; work through the fictional inspection stories without disclosing real memory.

Find, redirect, and leave an already-running tangent

Start with the current recipient, then distinguish steering, follow-up, observation, revival, cancellation, and explicit kill; do not substitute a Main session reset for a focus change.

Give an agent a capability without giving it a blanket grant

Follow the smallest-surface decision through shared human/tool behavior, branch-aware state, one-action authority, portable UI, and realistic verification.

Keep delayed results with the conversation that requested them

Use this route when a result arrives twice, disappears from later job snapshots, or reaches the wrong branch; distinguish work lifetime, owner identity, committed body, and wake-up.

Inspect a complete packet without a live share

Choose the correct snapshot, inspect older and nested fictional history, and separate local acceptance, external script loading, redaction, encryption, and disclosure authorization.

Explain and repair a blocked or unexpectedly unprompted tool call

Identify the exact operation and current scope, trace the effective policy through modes, rules, dispatch, launch inputs, and child construction, then choose a bounded recovery without making yolo the default fix.

Try the fictional Memory lab

The original interactive simulator keeps its five fictional stories and controls. It does not read your memories, sessions or credentials.

Open the local Memory lab

The lab has its own window.memoryTutorial interface. This book’s window.ompWorkbook interface does not cross into that document.

Follow the examples

Reading illustration; does not inspect or control OMP.

With JavaScript off, all supplied stories and milestones are readable below.

Seed Desk: grow a useful helper

A fictional community seed library grows from a welcome command into inventory queries and branch-local reservations. Run one stage at a time.

A command and an agent-readable welcome

Goal: Let a volunteer and an agent discover the same desk information.

Actions in the example

Load seed-desk/01-welcome/index.ts with an explicit OMP extension path.
Human: /seeds welcome or /seeds hours.
Agent: seed_welcome with op discover, then inspect a discovered topic.

Recorded observations

Both surfaces read the same greeting.
An exact completion returns no suggestion, releasing Enter for submission.
The seed-quiet CLI flag suppresses the startup notice, not the tool.

Source files

Evidence limits

No reservation operation exists.
Completion behavior was exercised through the registration API, not a physical terminal.

One catalog, two interfaces

Goal: Answer concrete inventory questions without duplicating domain behavior.

Actions in the example

Load only seed-desk/02-catalog/index.ts.
Human: /seeds query herb or /seeds inspect basil-genovese.
Agent: seed_catalog query or inspect.

Recorded observations

The herb query returns basil-genovese with eight fictional packets.
Unknown IDs fail; a pre-aborted call is refused.
Read operations append no reservation state.

Source files

Evidence limits

The JSON fixture is not a live stock service.
No provider-driven tool choice was exercised.

Authorize a guarded reservation

Goal: Let a human grant and revoke agent authority over one branch's fictional reservations.

Actions in the example

Load only seed-desk/03-reservations/index.ts.
Human: /seeds agent on, then confirm the scoped grant.
Agent: seed_desk discover, inspect, then act with the current revision and exact item.
Human: /seeds agent off to revoke.

Recorded observations

Stale revisions, invalid targets, bad quantities and over-reservation are refused.
Cancelled confirmations append no state.
Real JSONL reopen restores the active branch; sibling branches remain separate.
Malformed saved data fails closed; fresh sessions start without reservations or grants.

Source files

Evidence limits

No real inventory or cross-process stock coordination.
UI confirmations in the core proof used a controlled delegate; filesystem failure recovery was not exercised.

Review Desk: make a decision before sharing

A local release note gains human review, explicit one-action agent permission, and an optional native overlay. Nothing is published or sent.

Read the draft without changing it

Goal: Expose the same local draft to a person and an agent.

Actions in the example

Load review-desk/index.ts.
Human: /review-desk show.
Agent: review_desk discover, inspect or query.

Recorded observations

A fresh session starts at draft revision 0 with authorization false.
Structured results contain the actual draft, not a screenshot.
A status line and string widget summarize the state when supported.

Source files

Evidence limits

The fixture file is never overwritten.
UI support differs between TUI, RPC, ACP and print modes.

Edit and accept locally

Goal: Make a deliberate human review decision through actual dialog surfaces.

Actions in the example

Human: /review-desk review.
Edit the multiline note; submit with the configured follow-up chord, not plain Enter.
Choose Accept locally.

Recorded observations

The edited note is stored in a custom session entry.
The status becomes accepted and revision advances once.
Real RPC editor and labeled-select request/response paths were exercised.

Source files

Evidence limits

Accepted is a local review label, not proof of external publication.
An RPC client must present and answer the dialog frames.

Keep rejection and cancellation distinct

Goal: Preserve the original note when the review does not accept the edit.

Actions in the example

Start /review-desk review.
Choose Reject, or dismiss the editor/selector to cancel.

Recorded observations

Rejected and cancelled are distinct persisted states.
Both preserve the pre-dialog note.
AbortSignal cancellation emits the matching RPC cancel target and settles the dialog.

Source files

Evidence limits

A cancelled review still records a review outcome and advances its revision.
This does not cancel an OMP background job or undo other tools' edits.

Grant exactly one agent change

Goal: Separate human permission from model-visible draft content.

Actions in the example

Human: /review-desk delegate, then confirm.
Agent: inspect the current revision and call review_desk act with that expectedRevision.
Use /review-desk revoke to remove an unused grant.

Recorded observations

One valid change consumes the grant.
Stale revisions and replay without a new grant fail without mutation.
Revocation closes pending grant/review dialogs; a late confirmation cannot restore authority or change the draft.
No-UI mode cannot create a new grant; authorization is not reconstructed from saved state.

Source files

Evidence limits

The permission check belongs to this extension's domain; it is not an OS sandbox.
The example has no network send or publish action.

Add a native review overlay

Goal: Make the same decision in a focused terminal component without replacing the draft in the composer.

Actions in the example

In TUI mode, run /review-desk overlay.
Use Up/Down to scroll; a accepts, r rejects, Escape cancels.

Recorded observations

Real controller/TUI key dispatch was exercised with a terminal emulator.
Closing the overlay disposes the component and preserves composer text.
Rendered rows sanitize control characters and obey narrow widths.

Source files

Evidence limits

Native components do not serialize over RPC.
This was not a physical-terminal visual audit or host desktop-control test.

Package Lab: move from a file to a distribution

A fictional field notebook demonstrates entry formats, module boundaries, resource discovery, optional plugin features and SDK binding.

Load one explicit file

Goal: Understand what an executable extension entry actually exports.

Actions in the example

From package-lab: omp --no-extensions -e ./single/field-notes.ts.
Try /field-notes reed, or field_notes discover/inspect/query.

Recorded observations

The default factory registers a human command and a read-only tool.
Unknown inspection IDs reject.
An explicit file remains an override of disabled-name filtering in this source.

Source files

Evidence limits

--no-extensions narrows ambient extension discovery; it is not a full isolation switch.

Separate an entry from its helper

Goal: Grow the implementation without accidentally loading every helper as another extension.

Actions in the example

From package-lab: omp --no-extensions -e ./multi.
Select fern with /notebook fern or the notebook tool; inspect with query.

Recorded observations

index.ts loads while notebook.ts remains an ordinary import.
Human and machine paths share factory-local selection.
An invalid selection leaves the prior selection intact; a new binding starts fresh.

Source files

Evidence limits

Selection is factory-local memory, not persistent session state; changing sessions does not itself create a new binding.
Prepared modules may be cached; mutable binding-local state belongs inside the factory.

Declare entries and optional features

Goal: Package the catalog and resource discovery without confusing explicit loading with plugin feature selection.

Actions in the example

From package-lab: omp --no-extensions -e ./manifest.
To load the optional entry without installing: add -e ./manifest/entries/summary.ts.

Recorded observations

The manifest declares two base entries.
Plugin feature selection can add a third entry; explicit manifest-directory loading does not select it.
resources_discover returns the real prompt path with entry provenance.

Source files

Evidence limits

No plugin installation or prompt-menu rendering was exercised.
Local link/install and marketplace scope rules are different; read the source-grounded instructions before installation.

Bind the same idea in an SDK host

Goal: Pass a factory, rather than a module path, into a deliberately configured session.

Actions in the example

Provide the workbook-compatible SDK dependency.
From package-lab: bun ./inline/run.ts.

Recorded observations

The real SDK binds the factory with isolated in-memory auth/session inputs.
The host prints registered metadata and disposes without prompting a model.
Rebinding creates fresh factory-local state; it does not transfer an already-bound runtime.

Source files

Evidence limits

SDK dependency and custom-build compatibility are explicit prerequisites.
No provider request or agent prompt loop was entered.

Separate coordination from privileged integration

Goal: Know which extension features work locally and which require a real host service.

Actions in the example

Run advanced/event-bus.ts as an explicit extension and inspect field_events.
Read the provider and file-fallback adapter contracts before supplying a genuine host configuration or broker.

Recorded observations

The process-local event bus publishes selection and unsubscribes at shutdown.
Factory failure rolls back provider registrations, not all arbitrary side effects.
Provider and file-fallback examples are explicit host adapters, not fake transports or elevated writers.

Source files

Evidence limits

No real provider, credential flow or privileged file broker was exercised.
Event emission does not await asynchronous listeners and is not durable delivery.

Return to yesterday's work

At the fictional Lantern Board, yesterday's conversation says Ready for pickup while today's workspace says Packed and waiting. Identify the intended journal, rehearse native resume and continue in a disposable lab, and distinguish selecting history from moving a project or restoring files.

Name what comes back

Goal: Distinguish durable identity, journal location, recorded cwd, active project cwd, and current workspace before selecting history.

Actions in the example

From examples/, inspect return-desk/yesterday.jsonl with the supplied jq commands and read return-desk/today.txt.
Record the fictional session identity 11111111-1111-4111-8111-111111111111, recorded /fictional/lantern-board cwd, yesterday's Ready for pickup text, and today's Packed and waiting label.
Do not treat cwd or the transcript as a workspace snapshot. Do not open the un-rebased fixture directly in a real profile.

Recorded observations

Reopening the fictional journal retained identity, journal location, history and cwd; workspace bytes did not change.

Source files

Evidence limits

This ledger concerns session continuity, not Git recovery, worktree isolation, or file rollback.

Copy fiction into an owned lab

Goal: Provide a real runnable reader setup without using or overwriting ordinary profile history.

Actions in the example

Run bun return-desk/lab.ts '{"version":1,"op":"discover"}'.
Run bun return-desk/lab.ts '{"version":1,"op":"act","action":"create"}'. Keep the JSON receipt; each create makes a new temporary root.
The receipt contains root, cwd, sessions, yesterday, prerequisites, native commands, and inSession commands. Re-inspect with version 1, op inspect, and the receipt root.
Set OMP_BIN to the intended installed OMP executable using the receipt's command. Native commands use env -i plus dedicated HOME/agent/XDG/TMPDIR paths, a synthetic terminal-identity fallback, and explicit --cwd/--session-dir. Keep resume and continue in the SAME actual terminal tab.
If interactive OMP stops at model/auth setup in the fresh profile, stop there: do not log in, paste keys, or copy credentials. Record native interaction as unverified and use the fixture inspection/proof report. No model prompt is part of this exercise.

Recorded observations

Public discover/create/inspect ran successfully inside the isolated proof; the copied journal opened through the real SessionManager.
Real source CLI startup resumed, continued and forked the generated lab using RPC inspection only. Each process exited successfully without model prompts or network attempts; physical TUI interaction was not tested.

Source files

Evidence limits

Bun is needed for lab setup; jq is optional for the separate inspection exercise; native interaction needs installed OMP and an interactive terminal.
A clean profile has no inherited auth and may not reach a usable interactive session. Stop at model/auth setup without providing credentials. Merely printing a command is not a passed native lab.
The helper is offline, but native OMP startup can discover providers or refresh metadata and may contact the network without a prompt. No blanket offline guarantee.
The config disables memory/autolearn/advisors/skills/secrets/marketplace auto-update, and native flags disable extensions/skills/rules/LSP/tools/title generation. This is data separation, not an OS sandbox for reader CLI.
No automated cleanup/deletion command is supplied. Only the new receipt root belongs to this exercise.

Choose the conversation, not just the newest file

Goal: Distinguish in-session /resume, startup --resume, local/global selection, and unknown identifiers.

Actions in the example

Run the receipt's resumeExplicitPath command; it points to the copied native yesterday journal, not a real user session.
Inside interactive OMP, enter /resume. The picker starts in current-folder scope; Tab switches all projects; Enter selects; Esc returns to the current session.
Use /resume 11111111-1111-4111-8111-111111111111 for direct ID lookup. The slash form resolves a native identity/filename prefix, not a direct filesystem path.
After exiting OMP, run the receipt's resumePicker command and cancel it. Startup picker cancellation exits rather than returning to an already active session.
Run the receipt's unknownIdentity command and inspect the failure; do not replace it with another session silently.
Check the active identity and cwd after a switch; do not treat a Resumed session status alone as conclusive.

Recorded observations

Resolver and command checks confirmed local-first matching, interactive global fallback, explicit startup-directory confinement and an unknown-ID error.
Actual picker component key handling selected and cancelled correctly. A controller test observed a success status after its switch collaborator returned false; check identity, not just status.

Source files

Evidence limits

Picker proof is component/controller-driven, not a physical terminal or complete InteractiveMode startup.
The controller collaborator uses real SessionManager.setSessionFile for state but not AgentSession.switchSession; real hook cancellation/rollback is assigned to decision-desk's SDK proof.
Startup empty-history and cancellation exit text are source-backed only in this slice.
Startup explicit --session-dir confines ID lookup. Interactive /resume explicitly allows global fallback even with an active custom session directory; Tab also requests the global native store.
Short prefixes are not guaranteed unique. The resolver takes the first match in its local-first listing; use a full known identity.
Unknown ID and missing path are different: SessionManager.open on an empty/missing explicit file starts a fresh identity and materializes a header at that path. Do not teach a typoed path as a guaranteed not-found failure.

Understand what continue chooses

Goal: Explain terminal breadcrumb priority, recent fallback, fresh boundaries, empty history, and persistent availability.

Actions in the example

After selecting yesterday in the lab and exiting, run the receipt's continue command in the SAME actual terminal tab with the same generated environment.
Observe the returned conversation rather than assuming --continue always means the newest file. The lab includes a newer unrelated note for comparison.
Use --resume with an exact known ID/path when you need a specific conversation. There is no interactive /continue slash command.
Keep in-memory availability separate: manager creation with --no-session returns an in-memory manager before string --resume/--continue processing. Do not infer that it prevents a later interactive resume or the separately routed bare startup picker.

Recorded observations

An older terminal breadcrumb beat newer history; stale missing-file breadcrumbs fell back, while a fresh boundary avoided resurrecting older history.
Empty history created a new identity. Existing other-project history was not adopted; a vanished source could be re-rooted when the destination lacked its own history.

Source files

Evidence limits

A terminal breadcrumb is terminal-scoped and stored separately from the journal. OMP prefers stdin's real TTY path; the helper's TMUX_PANE value is only a synthetic fallback when no TTY path is available. Use the SAME actual terminal for reader resume then continue. Fresh HOME/agent paths still isolate lab breadcrumb storage.
A fresh not-yet-materialized breadcrumb suppresses resurrection of older history. Assigned transcript path is not evidence that a durable file exists.
Nested artifact breadcrumb recovery to the interactive root is source-backed but not executed in this proof.
autoResume and --continue full-UUID compatibility normalization are source-backed, not included in the prepared runtime scenarios.

A missing project is a different decision

Goal: Separate ID-based relocation consent from direct-path fallback, runtime cwd fallback, and automatic continuation relocation.

Actions in the example

Use the source-backed decision table, not a destructive reader exercise: for --resume <id> whose matched journal records a vanished cwd, Yes/default re-roots that same session into the launch directory; No cancels startup; non-TTY cannot supply consent and errors.
Contrast --resume <path.jsonl>: direct path opening bypasses the ID relocation prompt. Missing recorded cwd falls back to the launch project without moving the journal.
Contrast in-session switching: missing recorded cwd keeps the current project rather than chdir into a nonexistent directory.
Contrast --continue: a terminal breadcrumb from a vanished project can be automatically re-rooted when the target has no history of its own.
Treat identity, journal location, active cwd, and workspace bytes as separate ledger columns after any transition.

Recorded observations

Injected relocation acceptance moved the same identity; decline returned no manager; unavailable consent produced an interactive instruction.
Direct-path opening retained journal location and fell back to launch cwd. Controller settings failure prevented switching; missing recorded cwd retained the current project.

Source files

return-desk/exercise.json

Evidence limits

No real missing directory or user project is touched. Proof deletes only its own empty synthetic source directory via rmdir inside a write-constrained temporary root.
Prompt answers are injected, not typed into readline. Default empty-answer acceptance and non-TTY detection are source-backed, not physically exercised.
No workspace moves/restores are implied. Re-rooting concerns the session journal/artifact namespace and its cwd, not repairing a missing project.

Explore another direction, then reset deliberately

Continue Return Desk's fictional Lantern Board lab using native OMP. Choose conversation boundaries without confusing them with workspace isolation or erasure. Private real-SDK fixtures independently use a fictional Cedar Library desk layout.

Explore another direction

Goal: Recognize new identity and retained parent history without claiming workspace isolation.

Actions in the example

Create the shared lab using decision-desk/commands.txt; record its fictional header and today.txt.
Run the receipt's complete resumeExplicitPath command. Stop if model/auth setup is required. Never submit a model prompt.
In the idle fictional conversation run /fork; keep the child active.

Recorded observations

Actual SDK/controller fork created a new persistent identity with parent metadata while retaining messages, queues and the parent journal. Workspace remained shared.
One artifact copied successfully; a blocked artifact destination was handled best-effort without rolling back the fork.

Source files

Evidence limits

Real SDK/controller/registry with inert UI, not rendered TUI proof.
Parent byte assertion is scoped to the fork call, not native startup/shutdown lifecycle records.
Artifact coverage is one ordinary file and one error, not symlinks, huge trees or remote backups.

Refresh the provider boundary

Goal: Refresh local provider state without resetting the conversation.

Actions in the example

Run /fresh in the idle fictional fork.
Observe retained transcript and local handle-pruning count; zero can be normal.
Compare persistent journal identity with provider-facing identity in the ledger.

Recorded observations

An inert provider handle closed and the provider-facing ID rotated; persistent journal identity, bytes, messages and ordinary queues remained unchanged. This does not prove remote recovery or erasure.

Source files

Evidence limits

No real provider request/auth/transport/recovery attempt occurs. Local handle closure cannot prove external recovery or remote deletion.
Native status is not a provider-ID inspector; the private SDK ledger measures that field.

Clear live context, keep the journal

Goal: Separate an empty live conversation from retained durable history.

Actions in the example

Run /clear in the idle fictional fork.
Predict which ledger columns change.
After exiting, inspect reset_boundary and retained fictional messages only in the lab files.

Recorded observations

Actual clear retained journal ID/path/title/model/cwd, cleared live messages and queues, and appended a reset boundary. Reopening rebuilt context after that boundary while earlier journal entries remained.

Source files

Evidence limits

Proof measures live state/context rebuilding, not the next model request.
Artifacts, exports, backups and provider copies are not removed.
Hidden-turn scheduling, actual jobs and compaction races are implementation-only details here.

Start another identity deliberately

Goal: Choose /new without deleting prior history or reverting files.

Actions in the example

Run /new, then exit without prompting.
Use provided shell queries for lab headers/messages/boundaries and today.txt.
Do not infer unchanged identity from absence of an empty new file.

Recorded observations

Actual new-session transition allocated another identity, emptied messages and queues, and retained the prior journal and workspace.
Drop was not executed. Source inspection shows best-effort deletion is not an erasure guarantee.

Source files

Evidence limits

An empty new transcript file may be deferred until persistable activity.
/new and /fork are not promised to roll back every possible failure atomically.
Drop is warning-only and not secure erasure: forks, exports, backups, workspace and provider copies can survive.

Fork at startup

Goal: Distinguish CLI launch cwd and persistence from interactive fork.

Actions in the example

Print and run the receipt's complete commands.forkExplicitPath native command.
Stop on model/auth setup; do not prompt.
Compare its child header with the interactive fork.

Recorded observations

Native parser/resolver checks retained source history and used launch cwd; combining fork with no-session was rejected.
A separate real CLI/RPC startup fork of the public lab returned a new identity, retained two messages and left workspace bytes unchanged.

Source files

Evidence limits

Private CLI layer is parser/manager resolver, not full startup/model selection/rendering.
Public native startup may contact metadata/auth services without a prompt; only private proof has OS network denial.
Explicit-path fork is exercised; source-ID fork lookup is implementation-only here.

Inspect identity after refusal or failure

Goal: Trust actual state rather than a blank screen or status label.

Actions in the example

Read failure cards without creating live streams/provider errors/destructive exercises.
Wait or abort normally before retrying a busy operation.
After veto/error, inspect active identity and conversation before further work.

Recorded observations

Synthetic streaming/foreground guards refused the tested operations. Actual extension vetoes preserved identity, messages and queues.
An injected switch failure after target loading restored prior identity, messages and queues. This is not a universal transaction guarantee for every operation.

Source files

Evidence limits

Synthetic predicates are not real cancellation/job-race proof. No providers, credentials, real sessions, clipboard, uploads or desktop interaction.
Rollback injection covers the guarded target-load block, not every failure before it or external side effect.
Resume selection/status repaint belongs to Return Desk; this slice owns underlying SDK veto/rollback.

Prepare a review packet without accidental disclosure

Use an entirely fictional Harbor Notes journal to distinguish live-context dumps, saved-history HTML exports and a separate publication decision. The packet is not a sanitization tool, a workspace backup, or evidence of erasure.

Choose the snapshot, not just a file extension

Goal: Predict which layer each command includes before creating an artifact.

Actions in the example

Read the interactive reference entries in review-packet/inspection-recipe.json; do not run /dump against personal history as an exercise.
Distinguish TUI /dump (clipboard text plus best-effort temporary LLM-context JSON), TUI /export [--themes] [path] (local HTML plus an OS-open request), and terminal omp --export input.jsonl [output.html] (file-based HTML and printed output path).
REVIEW BEFORE SHARING any dump or sidecar: both may contain system context and tool descriptions; the sidecar includes converted messages and tool wire schemas.
Recognize that /dump formats current live messages, while HTML takes all SessionManager journal entries, not only the post-reset model context.

Recorded observations

Dump used live context and wrote a best-effort raw sidecar; an injected converter failure left the plain transcript available. In-memory dump worked while HTML export was rejected.

Source files

review-packet/inspection-recipe.json

Evidence limits

The proof never invokes the TUI clipboard path. Plain-output builtin dump behavior is exercised instead; TUI clipboard copying and its sidecar-error status wording are source-inspected only.
The sidecar is a convertToLlm-boundary snapshot, not a captured exact HTTP request or proof that any provider call occurred.
The formatter always includes a Configuration section; an empty message array does not necessarily yield empty text. Only dumpLlmRequestToTmpDir explicitly returns undefined for zero messages.

Export fictional saved history locally

Goal: Create a local packet, identify its external viewer dependencies, and inspect all embedded history, including nested agents.

Actions in the example

From the extracted examples directory, run omp --export review-packet/harbor-review.jsonl review-packet/harbor-review.html.
Offline check: block external requests and open the HTML. Expect controls but NO transcript, as Main verified. Do not ask the reader to find messages or navigate agents in this state.
Offline fallback: inspect review-packet/harbor-review.jsonl as plain text for CURRENT-CONTEXT and PRE-CLEAR-HISTORY; inspect review-packet/harbor-review/Scout.jsonl and review-packet/harbor-review/Scout/Checklist.jsonl directly for nested transcripts. The main fixture includes a saved reset_boundary between earlier and current messages.
Optional fictional preview: explicitly choose whether to permit the two public CDN script requests. If permission is declined, stay with the JSONL fallback. If permitted, reload the fictional HTML, find both main-history markers, then open Scout and Checklist; Escape returns to Scout. This external-code loading choice is separate from export generation and from /share.
Inspect header paths, old entries, tool inputs/outputs and all nested data before any disclosure. The visible leaf is not the complete file.

Recorded observations

HTML embedded pre-clear journal history and recursive Scout/Checklist transcripts. Live export included explicitly fictional current system/tool metadata; file export did not reconstruct it.
Headless browser navigation opened Scout, then Checklist, and Escape returned to Scout. Blocking the two CDN scripts left controls but no rendered transcript: embedded data does not make an offline viewer.

Source files

Evidence limits

Public fixtures are hand-authored fictional JSONL, not exports of any real OMP session. Generated HTML is written only to private proof/review-packet/artifacts until Main reviews it.
TUI/live export adds current state.systemPrompt joined with blank lines and current tool names/descriptions. File export does not reconstruct a live prompt or tool inventory, although arbitrary saved entries can themselves contain sensitive context.
Subagents are found only by the sibling <session-stem>/<AgentId>.jsonl convention, recursively; missing directories, .bak filenames, and empty/corrupt files are omitted. Not every possible artifact is embedded.
includeSubSessions:false is a programmatic ExportOptions setting, not a documented /export command flag.
NOT a self-contained offline viewer: template.html:50-51 and generated HTML reference marked/15.0.4 and highlight.js/11.9.0 on cdnjs.cloudflare.com. Main verified that blocking both scripts leaves controls but NO transcript, not merely degraded formatting. Offline review must use raw JSONL. Rendered nested navigation requires a separate explicit choice to load those external scripts for the fictional preview. Proof reports offlineViewer.available:false as an availability limitation; no production fix is included.

Recover from a path or persistence mismatch

Goal: Understand why terminal quoting and interactive export parsing differ.

Actions in the example

Compare terminal shell quoting with interactive whitespace splitting. The recipe provides a runnable quoted terminal output filename.
Use a no-space interactive output path. /export "packet review.html" is invalid even with quote characters because parseExportArgs does not implement shell quoting.
Treat /export --copy, /export copy and /export clipboard as warnings directing you to /dump, not successful HTML exports.
Do not infer persistence from an available dump. In-memory live messages can be formatted and written to a temporary sidecar; exportSessionToHtml rejects a manager without a session file.

Recorded observations

Slash parsing rejected a spaced path; shell argv preserved spaces. The actual CLI exported to a filename containing spaces and exited successfully.
Interactive copy aliases only warned; export browser requests were intercepted and no clipboard action occurred.

Source files

review-packet/inspection-recipe.json

Evidence limits

parseExportArgs recognizes only --themes. It does not perform shell expansion, quoting, or general flag validation; an unrecognized single token can be a literal filename.
Terminal --export stores its input path as the flag value; main.ts uses the first positional message as the output path and returns before normal session startup. It does not use the interactive parser or expose the interactive --themes syntax.
An output write error is surfaced; this is not an automatic retry, mkdir policy, or transactional export guarantee.

Keep local review separate from publication

Goal: Understand current sharing boundaries without sending any data.

Actions in the example

Do not execute /share in this workbook exercise. Read the isolated, intercepted proof results after Main runs them.
Distinguish current default share.store=blob from optional share.store=gist. The default uploads an encrypted session JSON snapshot to the configured share server; optional gist uses gh and falls back to the server if unusable.
Treat share.redactSecrets=true as configured secret replacement, not a universal privacy guarantee: no obfuscator or no recognized secrets skips the typed redaction pass; unknown strings and image bytes may remain.
Review custom TUI share scripts as a separate policy boundary. They receive an ordinary standalone HTML path, not the default encrypted/redacted snapshot.
Treat an Escape cancellation message as UI cancellation only. A started upload or custom handler can still finish and produce an external effect after the URL display is suppressed.

Recorded observations

Intercepted default sharing encrypted the snapshot, removed configured secrets, retained an unknown fictional string and omitted adjacent nested transcripts. Local/custom HTML did not apply that share redaction.
Tests exercised image/text trimming, gist-to-server fallback, custom-handler failure without fallback, and completion after Escape. No live upload, real provider call or destructive reader action occurred.

Source files

review-packet/inspection-recipe.json

Evidence limits

Current source contradicts old documentation/comments saying GitHub Gist is the default or preferred route. settings-schema.ts sets blob as the default. There is no --gist flag in this slice.
shareSession builds a snapshot directly from the manager and optional live state; it does not collect adjacent subagent transcripts. Custom HTML export does collect them by default.
Default encryption is gzip(JSON) sealed using a fresh AES-256-GCM key and 12-byte IV. The link fragment carries the key; sharing the whole link shares decryption access. Encryption is not redaction.
Typed redaction covers specific text-bearing fields, drops specified opaque provider/extension payloads, and leaves image bytes intact before size trimming. Do not describe it as a universal walk of every field or a scrub of every header path.
Server sealed-byte budget is 1,000,000; gist budget is 5,000,000. Trimming strips large inline images/data URLs, then progressively caps strings at 32768/8192/2048/512, then halves oldest entries while more than four remain; it throws if still too large. Size trimming is lossy, not privacy review.
Custom script lookup uses getAgentDir(), checking share.ts then share.js then share.mjs. Invalid module/default export or handler failure does not fall back to default sharing. A custom script is trusted executable code.
Custom result may be a URL string, an object with optional url/message, or undefined. TUI opens returned URLs only after non-cancelled completion; temp HTML removal occurs in finally after settlement, with removal failure ignored.
TUI cancellation does not pass the loader AbortSignal into shareSession or the custom callback. Late completion/errors are suppressed from the UI; this is not upload revocation or rollback.
The shared non-TUI builtin share handler calls shareSession directly; it does not load the custom TUI share script.
The proof intercepts fetch in one isolated child and restores it. A fake unauthenticated gh records auth status only. No GitHub account, relay, real credential or network endpoint is contacted.

Approval Desk: predict the applicable policy

Read the fictional Cedar Seed Library cases to distinguish tier defaults, explicit policies, keyed fallback, and ordered shell classification without executing a command.

Predict the baseline before looking for an override

Goal: Separate a declared tier from the mode that admits or prompts it.

Actions in the example

Read the nine mode/tier cases in approval-desk/cases.json and predict allow or prompt before inspecting expected.
Compare approval-always-ask-read, approval-always-ask-write, and approval-always-ask-exec.
Compare approval-write-read, approval-write-write, approval-write-exec, approval-yolo-read, approval-yolo-write, and approval-yolo-exec.
Finish with approval-undeclared-exec and explain why an omitted declaration is not read.

Recorded observations

The supplied executed report records allow/prompt/prompt for approval-always-ask-read, approval-always-ask-write, and approval-always-ask-exec.
It records allow/allow/prompt for approval-write-read, approval-write-write, and approval-write-exec, and allow for all three approval-yolo cases.
approval-undeclared-exec resolved to exec-tier prompt from mode in write mode.
All ten of these cases exercised resolveApproval/requiresApproval with zero tool executions.

Source files

approval-desk/cases.json

Evidence limits

These are resolver observations, not displayed dialogs or executed operations.
Read tier does not certify zero effects or no network activity.
The website selects this authored milestone; it does not inspect the reader's mode.

Resolve policy conflicts by source

Goal: Explain why denial is special without claiming all user policy always wins.

Actions in the example

Predict the winner in approval-tool-deny-wins and approval-user-deny-wins.
Compare approval-explicit-tool-prompt with approval-tool-allow-before-user-prompt.
Write the winning source beside each policy result, then compare with the manuscript's precedence table.

Recorded observations

approval-tool-deny-wins denied from tool policy despite user allow and yolo, retaining the fictional desk-closed reason.
approval-user-deny-wins denied from user policy despite explicit tool allow and yolo.
approval-explicit-tool-prompt remained a tool-sourced prompt in yolo.
approval-tool-allow-before-user-prompt returned tool-sourced allow in always-ask despite the user prompt value.

Source files

approval-desk/cases.json

Evidence limits

The results establish resolver precedence, not a domain authorization system.
Override-only prompting and explicit prompt policy are different source branches.
No policy changes are requested by this stage.

Find the effective user-policy identity

Goal: Distinguish a device-specific policy from the invoking-tool fallback.

Actions in the example

Read approval-policy-key-fallback and identify the invalid keyed value.
Read approval-policy-key-specific and normalize its whitespace-padded allow value on paper.
Explain why write deny is effective in one case but only an unused fallback in the other.

Recorded observations

approval-policy-key-fallback resolved to user deny with policyKey write.
approval-policy-key-specific resolved to user allow with policyKey seed_slot, replacing the invoking write deny fallback.
Both cases executed the actual resolver and requiresApproval helper without executing a tool.

Source files

approval-desk/cases.json

Evidence limits

Normalization of a policy value is not validation of all raw configuration or every later consumer.
The wrapper has an additional raw own-property predicate for forwarded prompting; that is explained from source, not exercised by these two resolver cases.

Follow rule order and command shape

Goal: Predict the first applicable rule rather than scanning for any deny.

Actions in the example

Treat every command field as inert text; do not paste it into a shell or OMP.
Predict bash-first-applicable-rule with its early printf allow and later catch-all deny.
Compare bash-compound-deny-segment and explain why its compound form cannot use the early allow.

Recorded observations

bash-first-applicable-rule returned a write-tier tool allow; the later deny was not selected.
bash-compound-deny-segment returned an exec-tier tool deny with reason Blocked by bash pattern: printf closed.
These cases called BashTool.approval and the actual resolver with zero shell executions.

Source files

approval-desk/cases.json

Evidence limits

Allow and deny/prompt rules use different matching semantics.
The matcher and shell-control checks are heuristics, not a complete shell security parser.
A rule-order lesson does not authorize installing a broad allow.

Distinguish critical override from explicit policy

Goal: Explain selected-deny, critical-heuristic, and selected allow/prompt order.

Actions in the example

Read bash-critical-before-allow, bash-critical-yolo, and bash-selected-deny-before-critical as classification cases only.
Name the returned declaration branch before applying the resolver's yolo behavior.
Contrast bash-explicit-prompt-yolo, whose noncritical pattern reaches an explicit prompt policy.

Recorded observations

bash-critical-before-allow resolved to exec-tier prompt with override true and Critical pattern detected.
bash-critical-yolo resolved to exec-tier allow from mode with override false.
bash-selected-deny-before-critical remained a tool-policy deny in yolo.
bash-explicit-prompt-yolo remained a tool-sourced prompt with the configured-pattern reason.

Source files

approval-desk/cases.json

Evidence limits

The recursive permission-change string is never an execution exercise.
The critical branch can precede the return of a selected prompt policy; do not infer universal yolo prompting from a catch-all rule.
All six bash scenarios are classification evidence, not safe-command certifications.

Dispatch Desk: follow the operation inside write

Trace the fictional seed_slot call through outer classification, keyed policy, inner enforcement, and supported argument replacement; count prompts separately from executions.

Decode the envelope and borrow the tier

Goal: Understand why a write envelope can carry a read-tier action or one approved reservation.

Actions in the example

Read the action objects in dispatch-inspect-no-ui and dispatch-reserve-once.
Identify write as the outer tool and seed_slot as the inner fictional tool.
Predict prompt, tool_call, and inert execution counts separately before reading the worked answers.

Recorded observations

dispatch-inspect-no-ui returned with read tier, zero prompts, two tool_call events, and one inert execution.
dispatch-reserve-once returned with write tier, one outer prompt, two tool_call events, and one inert execution.
The reservation prompt named write, xd://seed_slot, and the reserve JSON payload; its choices were Approve and Deny.

Source files

dispatch-desk/cases.json

Evidence limits

The private path uses actual WriteTool/dispatch/wrapper code around an in-memory recording tool, not a real inventory device.
xdevApproved is a supported duplicate-prompt mechanism, not general delegated authority.
No fictional call should be submitted to the reader's OMP session.

Choose the device policy or the invoking fallback

Goal: Explain an outer refusal and an unexpectedly unprompted keyed action.

Actions in the example

Compare dispatch-fallback-deny with dispatch-specific-allow.
Identify the effective user-policy key in each case.
Explain the publish action string as an exec-classification fixture, not a publication capability.

Recorded observations

dispatch-fallback-deny threw a user-policy refusal naming write with zero prompts, zero tool_call events, and zero inert executions.
dispatch-specific-allow returned at exec tier with zero prompts, two tool_call events, and one inert execution despite the generic write deny fallback.
The recorded executor output in the successful case stated Recorded fictional call; no external operation.

Source files

dispatch-desk/cases.json

Evidence limits

A valid keyed policy replaces the invoking fallback; this is not an intersection of all entries.
Neither case establishes remote permission, an OS grant, or a real publishing effect.
Correcting the explanation does not authorize changing any policy.

Keep inner enforcement visible

Goal: Separate duplicate questions from duplicate execution and outer tier admission from inner deny.

Actions in the example

Read dispatch-explicit-prompt-twice and correlate the write and seed_slot lifecycle pairs.
Compare dispatch-inner-tool-deny, where the inner declaration denies before its handler event.
Count underlying executor entries rather than inferring them from prompt count.

Recorded observations

dispatch-explicit-prompt-twice recorded two Approve selections, two tool_call events, one inert execution, and write tier.
dispatch-inner-tool-deny returned isError true with a tool-policy refusal, one outer tool_call event, zero prompts, and zero inert executions.

Source files

dispatch-desk/cases.json

Evidence limits

The double prompt is the current tested explicit device user-policy path, not a promise for every nested prompt declaration.
Write borrows the target tier, not the entire target policy.
A returned error result is not success merely because the transport did not throw to its caller.

Reconsider changed or invalid input

Goal: Follow supported inner replacement through reclassification and distinguish it from payload validation failure.

Actions in the example

Predict dispatch-rewrite-prompts after inspect is replaced by publish with the revised fictional note.
Compare dispatch-rewrite-denies after inspect becomes blocked.
Read dispatch-malformed-json without attempting to repair or submit it to a live host.
Compare the rewritten executor input with the returned xdev args and tier in the manuscript's recorded explanation.

Recorded observations

dispatch-rewrite-prompts displayed the revised publish action, returned exec tier, and recorded one inert execution after one prompt.
Its returned xdev.args still contained inspect while the executor ledger contained the replacement and xdev.tier was exec.
dispatch-rewrite-denies returned a tool-policy error with exec tier, two tool_call events, and zero prompts or inert executions.
dispatch-malformed-json returned an error explaining that a JSON args object was required, with one outer event and no inert execution.

Source files

dispatch-desk/cases.json

Evidence limits

The supported bypass check uses object identity; these cases do not establish a deep-mutation or universal stale-input guard.
Direct/nested execution is not evidence that agent-loop schema revalidation occurred.
Ordinary file paths, SSH escalation, device-only transport restrictions, and same-tool native delegation are explained from their own source/tests, not assumed identical to this route.

Boundary Desk: one decision, one effect boundary

Read recorded one-call answers, execute-time overrides, UI transport cases, synthetic provider checks, and a denied file primitive without turning them into blanket grants.

Approve, deny, dismiss, then ask again

Goal: Learn the actual binary response and its non-persisting lifetime.

Actions in the example

Compare boundary-approve-one-call, boundary-deny-one-call, and boundary-dismiss-one-call.
Read boundary-approval-does-not-persist with its two calls and Approve-then-Deny responses.
Explain why fixture null represents undefined rather than another dialog button.

Recorded observations

boundary-approve-one-call recorded one prompt and one inert execution.
boundary-deny-one-call and boundary-dismiss-one-call each recorded one prompt, zero inert executions, and the user-denial error.
boundary-approval-does-not-persist recorded two prompts, two tool_call events, one successful call, and one inert execution before the second call was denied.
The recorded selectors offered exactly Approve and Deny.

Source files

boundary-desk/cases.json

Evidence limits

The recording adapter is not proof of a physical human answer.
There is no allow-for-session or always-allow choice in this generic wrapper.
Declining the second call does not undo the first call's effect, even though that effect is only an inert ledger entry here.

Explain automatic admission and early denial

Goal: Distinguish execute-time autoApprove from configured mode and from explicit denial.

Actions in the example

Predict boundary-auto-approve-mode with configured always-ask, autoApprove true, and no UI.
Compare boundary-auto-approve-still-denied.
Read boundary-deny-before-handler and explain why the proposed replacement is never used.

Recorded observations

boundary-auto-approve-mode returned with zero prompts and one inert execution.
boundary-auto-approve-still-denied threw a user-policy refusal with zero events, prompts, and inert executions.
boundary-deny-before-handler threw a tool-policy refusal with zero events, prompts, and inert executions.

Source files

boundary-desk/cases.json

Evidence limits

These cases inject execute-time context; they do not test CLI parsing or a full launch.
CLI flag combination behavior is traced separately through main.ts, args.ts, and the SDK.
An early direct-wrapper denial is not a claim that no upstream loop path could already have emitted an event.

Distinguish an unavailable UI from an RPC selection

Goal: Follow a semantic selection without claiming a terminal exists.

Actions in the example

Read boundary-no-ui and identify its false resolution despite zero displayed prompts.
Compare boundary-rpc-approve and boundary-rpc-cancel.
Separate the helper request/response result from full RPC host construction and physical client presentation.

Recorded observations

boundary-no-ui recorded approval requested then resolved false with reason no interactive UI available, with zero prompts and executions.
boundary-rpc-approve exercised one real select-helper request and correlated synthetic response, producing one inert execution.
boundary-rpc-cancel exercised one select-helper request, converted cancellation to undefined, and produced no inert execution.
Both RPC helper cases left zero pending requests in their maps.

Source files

boundary-desk/cases.json

Evidence limits

Full runRpcMode initialization and a real stdin/stdout client were not launched by these scenarios.
RPC adapter construction is source-backed; ACP form behavior is source-backed and capability-dependent.
hasUI is not physical terminal proof and does not establish native component support.

Keep pending safety acknowledgement separate

Goal: Explain why ordinary automatic approval does not acknowledge synthetic provider checks.

Actions in the example

Predict boundary-provider-check-no-ui despite read tier, yolo, autoApprove, and user allow.
Read boundary-provider-check-approved and locate the fictional check text in the prompt.
State exactly what providerSafetyApproved proves in this recording.

Recorded observations

boundary-provider-check-no-ui refused with no inert execution and providerSafetyApproved false.
boundary-provider-check-approved recorded one prompt containing Fictional seed shelf check, one inert execution, and providerSafetyApproved true.

Source files

boundary-desk/cases.json

Evidence limits

The metadata was synthetic; no provider request, screenshot, or desktop action occurred.
The flag transition is not an OS permission grant or a complete provider safety proof.
The synthetic computer event view is not ordinary replacement input.

Locate the later host error

Goal: Distinguish approval from a denied primitive and classify error evidence accurately.

Actions in the example

Read boundary-fallback-no-handler and predict the number of primitive attempts with no registered handler.
Compare boundary-fallback-code-precedence and boundary-fallback-message.
Finish with a recovery note that retains the error and does not propose yolo, a privileged broker, or cleanup.

Recorded observations

boundary-fallback-no-handler made one injected primitive attempt and rethrew the identical synthetic EACCES error, with no successful effect.
boundary-fallback-code-precedence classified the structured ENOENT as not permission-denied despite EACCES appearing in the message's path.
boundary-fallback-message classified an unstructured Error containing EACCES as permission-denied.

Source files

boundary-desk/cases.json

Evidence limits

No fallback handler, elevated writer, OS grant acquisition, privileged success, or delete operation was exercised by these private cases.
The supported write/delete fallback routes and process-wide registry lifetime are separate source contracts.
Classification is not recovery, and reading this milestone changes no personal state.