@danypops/papyrus 0.34.3 → 0.35.1

package/README.md

@@ -1,24 +1,6 @@
-# Papyrus
+# @danypops/papyrus
 
-Graph artifact service for Pi — enforced SQLite schema, domain tools and services, and native interactive frontends.
-
-Artifacts are rows in SQLite. Edges are typed relations. Kinds and relations are **registered and enforced**—the schema is the protocol. A supervised Bun daemon is the sole database owner; Pi extensions and other clients use its authenticated loopback service API.
-
-## Architecture
-
-```text
-Pi tools + TUI
-      ↓
-tasks / notes / docs / rules / skills domain tools
-      ↓
-Papyrus client → authenticated loopback daemon
-      ↓
-operation registry + lifecycle services
-      ↓
-graph-store operations → SQLite (WAL)
-```
-
-The `papyrus_*` tools remain low-level administration escape hatches. Normal agent work should use the domain tools.
+The daemon, CLI, and domain services behind Papyrus's graph artifact store. Installable and runnable standalone, with no Pi dependency — the Pi extension lives in the sibling `@danypops/pi-papyrus` package.
 
 ## Storage and service
 
@@ -46,7 +28,7 @@ papyrus notes capture "Review release provenance later"
 papyrus notes list --json
 ```
 
-For repository work, install the versioned ownership guard once:
+For repository work, install the versioned ownership guard once (from the workspace root):
 
 ```bash
 bun run guard:install
@@ -106,27 +88,6 @@ Artifacts are never hard-deleted on request: every artifact gets a permanent, im
 
 Once the deadline passes, the daemon's periodic sweep performs a real, cascading, irreversible deletion — the one deliberate, narrow exception to Papyrus's otherwise-absolute append-only history, enforced by the database itself (not merely application code) via a trigger condition checked at delete time.
 
-## Tools
-
-The `papyrus_*` tools are the low-level graph-store API:
-
-- **`papyrus_query`** — filter by kind/status or search title and body
-- **`papyrus_graph`** — link artifacts, perform bounded traversal, or read the mutation event log
-- **`papyrus_show`** — read nested metadata and bounded edges, optionally running gates
-
-Agent-facing domain tools own lifecycle invariants and sit above this store API:
-
-- **`tasks`** — create/update/list/show/plan, manage the singleton active focus, replace evidence-bearing checklists, hierarchy/dependencies, lifecycle transitions, non-blocking gates, and review completion that focuses one deterministic ready successor without claiming effort
-- **`notes`** — capture/list/show deferred human intent, mark it consumed, promote it to an existing Task/Doc/Rule/Skill, or archive it with an explicit disposition
-- **`docs`** — create/update/list/show, activate/archive/reopen, and document-safe graph links; Note mutations remain behind the Notes facade
-- **`rules`** — create/update/list/show/preview, enable/disable, and attach governance gates to tasks
-- **`skills`** — create/update/list/show/invoke/run, enable/disable, create compatibility templates, and atomically instantiate parameterized workflow runs
-- **`playbooks`** — a completely different beast from Skills, not a subtype: a trigger and an ordered list of steps an agent reads and follows, never mechanically instantiated and never composed the way Skills call other Skills. create/update/list/show/invoke, enable/disable. A Playbook can declare named arguments (`{name, description?, required?}`, required defaults true); invoking with some unsupplied lists exactly which required ones are still missing and directs the agent to ask via `discuss` with `live:true` rather than guess
-
-Every tool operation is registered in the daemon’s `/api/v1/ops` registry; parity is verified in tests. The task consumer uses the `tasks.graph` operation, which returns task nodes with explicit parent, child, and dependency IDs rather than leaking SQLite rows or asking the UI to reconstruct relationships.
-
-Internally, application services depend on the `ArtifactStore` and `GateRunner` ports. SQLite and subprocess execution are adapters composed only by the daemon; task behavior is unit-tested against fakes without a database. Task visualization projects the same `TaskGraph` into semantic display graphs and sends them through a `GraphRenderer` port; the Pi adapter uses `beautiful-mermaid` for terminal Unicode output without leaking Mermaid syntax into the task domain.
-
 ### Naming vs. ids
 
 Every agent domain tool (tasks, docs, rules, skills, notes, discuss) addresses its artifacts by `name` (the exact title) wherever `id` would otherwise be required -- `dependency_name`/`parent_name`/`child_name`/`root_task_name`/`depends_on_names` (tasks), `target_name` (docs link, searches every kind since a link target can be any of them), `task_name` (rules gate, discuss block/unblock), `template_name` (skills instantiate), and `blocks_task_names` (discuss open) are the name-based equivalents of their `*_id` counterparts. Resolution is an exact, case-insensitive, trimmed title match scoped like a plain list call; an unmatched or ambiguous name fails with a clear error (ambiguous names list the real ids, since that's the one point disambiguation genuinely needs them). Results returned to the agent likewise lead with name and status, never id, unless two artifacts in the same result share a title -- id is a backend implementation detail, not a conversational handle. `id` itself still works exactly as before for every action, in every tool.
@@ -135,151 +96,6 @@ Every agent domain tool (tasks, docs, rules, skills, notes, discuss) addresses i
 
 Tasks, Docs, Rules, and Skills all support first-class `update` (title/body/labels, at least one required) alongside creation -- a Doc's body is no longer immutable once created. Every update is bounded the same way creation is (Rules keep their own stricter combined condition+action+body ceiling; Docs/Skills share Tasks' own length bounds) and recorded on the artifact's append-only mutation history, queryable via `graph.history`. An artifact carrying a `source:<system>` label (e.g. `source:web-spider` on an ingested page) is a read-only projection from a system Papyrus doesn't own the source of; updating one is refused with a clear error rather than silently forking it -- capture a correction as a new linked Doc instead until a write-back capability to that system exists. Notes stay behind their own facade for any content change, same as every other Notes mutation.
 
-## Interactive frontends
-
-- `/tasks` — project/focused-graph scope, task lifecycle, append-only history, gates, dependencies, and nested metadata
-- `/note <request>` — directly capture one project-scoped deferred request without creating a Task
-- `/notes` — searchable project Notes inbox with consume, promote, and disposition-aware archive actions
-- `/docs` — searchable non-Note documents, lifecycle, details, edit, and graph links
-- `/rules` — severity/condition rows, exact injection preview, edit, enable/disable, and task gating
-- `/skills` — trigger/tools rows, edit, invocation into the editor, and artifact templates
-- `/playbooks` — trigger/tools rows, edit, invocation into the editor, and graph links
-- `/playbook <name>` — tab-completes active playbook titles and places that one's invocation directly in the editor, one step instead of browse-then-select; no argument falls back to the full `/playbooks` browser
-
-All frontends use daemon-backed domain operations; none opens SQLite from the Pi process. **Show details** opens a bounded navigable view across Tasks, Notes, Docs, Rules, legacy Skills, templates, and workflow Skills. User-authored bodies render as width-aware Markdown with headings, emphasis, links, quotes, lists, tables, inline/fenced code, syntax highlighting, and every color/decorative style derived dynamically from the active Pi theme. Generated lifecycle, metadata, checklist, gate, history, and relationship sections keep explicit semantic theme colors. `↑/↓` scrolls, `←/→` pans wide relationships, and Esc returns to the browser; non-interactive clients receive stable source text.
-
-## Notes
-
-Notes are project-scoped `doc/note` artifacts for human requests that should be considered later. Capturing a Note does not create work, inject the entire inbox into prompts, or imply acceptance. The agent can use the `notes` domain tool to list and consume open Notes, decide whether to create a Task, Doc, Rule, or Skill through its owning domain tool, then promote the Note by linking that artifact. Archive requires one of `completed`, `duplicate`, `declined`, or `superseded`; promote archives with a `promoted` disposition and target ID. Capture, consumption, and disposition provenance remain in bounded Note history.
-
-The default inbox contains draft and consumed/active Notes, is bounded to 50 rows, and has a hard limit of 200. Bodies are capped at 10,000 characters. Generic document and graph lifecycle operations reject Note mutations so they cannot bypass disposition provenance.
-
-```bash
-papyrus notes capture "Investigate the retry policy" --json
-papyrus notes list --limit 25 --json
-papyrus notes show <note-id> --json
-papyrus notes consume <note-id> --json
-# Create the resulting artifact with tasks/docs/rules/skills first, then:
-papyrus notes promote <note-id> <target-id> --reason "Converted to tracked work" --json
-papyrus notes archive <note-id> declined --reason "No longer relevant" --json
-```
-
-## Discuss
-
-Discuss is a native, persistent deliberation, distinct from a one-shot ask: it survives across turns and sessions, takes multiple rounds, and can genuinely block a Task's completion until settled or deferred. A Discussion is a `doc` artifact with `subtype: "discussion"` -- real graph citizenship (edges, show/list) without a fifth enforced artifact kind. Its fine-grained lifecycle (`active`/`deferred`/`settled`) lives in `extra.discussion`, since Papyrus enforces status vocabulary per kind, not per subtype.
-
-Rounds are a dedicated append-only child table (mirroring Task history's own shape): `open` records round 1, `reply` appends further rounds, refused once the Discussion is `deferred` or `settled` -- resume first. `defer` is explicitly non-blocking (paused, reason optional, resumable); `settle` is terminal, records an outcome, and archives the Doc. `block`/`unblock` manage the blocking relationship to a Task independently of `open`.
-
-Blocking is real: `tasks.complete` is refused while any `active` Discussion has a `blocks` edge to that Task. A `deferred` Discussion does not block -- "we will get back to this" is distinct from "resolved."
-
-`open`/`reply` can also pose a structured choice instead of (or alongside) free text: `options` (2-10 entries) plus `options_mode` -- `single` is mutually exclusive (exactly one pick), `multi` allows several. The Discussion remembers the pending choice (`extra.discussion.pendingOptions`/`pendingOptionsMode`) until a `reply` answers it with `selected`, validated against exactly what was offered and the mode's cardinality; a reply can also pose the *next* round's choice in the same call.
-
-Run `/discuss` for the interactive panel: browse every Discussion (the real `active`/`deferred`/`settled` state shown per row, alongside any choice awaiting an answer), open a scrollable transcript showing what was posed and picked in each round, and reply/defer/resume/settle or block/unblock a task without leaving the TUI. Replying to a pending choice shows a real picker -- the native single-select list for `single`, or a checkbox multi-select for `multi`, since no built-in multi-select exists in the Pi extension UI. Both modes append a numbered "type your own answer" row -- a genuinely open answer is exactly as valid as any posed option. The multi-select picker supports a number key as a direct quick-select (jump straight to that row instead of scrolling), and steadily highlights checked rows while dimming the rest so the eye reads "what's chosen" independent of cursor position; its cursor row blinks to mark focus. It also auto-cancels after 30s of zero input -- the very first keystroke of any kind stops that countdown permanently for that prompt. Opening a *new* Discussion is left to the agent (same as Docs/Rules/Skills) -- `/discuss` browses and drives existing ones.
-
-```bash
-papyrus discuss open --title "Naming" --actor alice --content "Should we rename this?" --blocks-json '["task-id"]' --json
-papyrus discuss open --title "Which approach" --actor alice --content "Pick one" --options-json '["A","B"]' --options-mode single --json
-papyrus discuss reply <discussion-id> --actor bob --content "I think so, here's why..." --json
-papyrus discuss reply <discussion-id> --actor bob --content "Going with B" --selected-json '["B"]' --json
-papyrus discuss defer <discussion-id> --reason "Waiting on design review" --json
-papyrus discuss resume <discussion-id> --json
-papyrus discuss settle <discussion-id> --settlement "Agreed: renaming to X" --json
-papyrus discuss show <discussion-id> --json
-```
-
-## Tasks
+Internally, application services depend on the `ArtifactStore` and `GateRunner` ports. SQLite and subprocess execution are adapters composed only by the daemon; task behavior is unit-tested against fakes without a database. Task visualization projects the same `TaskGraph` into semantic display graphs and sends them through a `GraphRenderer` port -- the Pi adapter (in `@danypops/pi-papyrus`) uses `beautiful-mermaid` for terminal Unicode output without leaking Mermaid syntax into the task domain.
 
-Run `/tasks` for the interactive task panel:
-
-- `/` filters; arrow keys navigate; Enter opens task actions; `s` switches among the persisted current-project, focused-root graph, and explicit all-projects views
-- `g` opens the programmatic Unicode graph; Tab switches dependency/composition views and arrow keys pan
-- routed graph layouts are bounded to 48 nodes/96 edges; larger graphs use a deterministic, box-drawn line fallback, and renderer failures are contained inside the viewport rather than escaping Pi
-- advance the `todo → in-progress → review → done` lifecycle; failed review becomes `rejected`, retry returns to `in-progress`, and `canceled` is terminal
-- use **focus** as the independent singleton Task selection that automatic continuation follows; focusing, pausing, or resuming never changes lifecycle
-- starting nested effort moves todo ancestors to in-progress; submitting enters review; completing review checks both typed checklist proofs and executable gates
-- passing review marks only that task done and focuses one deterministic ready successor while leaving the successor todo until effort starts
-- successors are never auto-completed; fan-in, fan-out, diamonds, and disconnected DAGs remain explicit
-- inspect deterministic execution layers, readiness, a box-drawn nested hierarchy, composition, dependencies, evidence-bearing checklists, and verification gates
-- lifecycle colors are semantic and redundant with text/glyphs: To-Do grey, in-progress yellow, review blue, rejected orange, done green, and canceled red; `▶` marks active focus
-- Show details keeps Checklist and Validation gates separate from incidental Metadata, renders bounded post-migration lifecycle history with actor/source/reason and gate evidence, then renders relationships as a Unicode box-drawing graph footer; `↑/↓` scrolls and `←/→` pans wide graphs
-- the compact persistent widget shows the current scope label plus bounded open work in containment order and always retains active focus when it belongs to that scope
-
-Authenticated CLI parity covers the changed lifecycle and focus operations:
-
-```bash
-papyrus tasks graph --json
-papyrus tasks scope --json
-papyrus tasks scope project --json
-papyrus tasks scope graph <root-id> --json
-papyrus tasks scope all --json
-papyrus tasks assign-project <task-id> [project-root] --json
-papyrus tasks active --json
-papyrus tasks history <id> --json
-papyrus tasks focus <id> --json
-papyrus tasks focused --json
-papyrus tasks pause --json
-papyrus tasks unpause --json
-papyrus tasks clear-focus --json
-papyrus tasks update <id> --title "Revised title" --body "Revised body" --json
-papyrus tasks update <id> --status todo --reason "created with legacy default" --json
-papyrus tasks start <id> --json
-papyrus tasks submit <id> --json
-papyrus tasks complete <id> --json
-papyrus tasks reject <id> --json
-papyrus tasks retry <id> --json
-papyrus tasks cancel <id> --json
-```
-
-### Focus-driven automatic continuation
-
-Automatic continuation is a property of the singleton Task focus, not a per-Task automation flag. An active focus continues at Pi's public `agent_settled` boundary when Pi is idle and has no queued messages. `tasks pause` preserves the focused Task while stopping continuation; `tasks unpause` resumes it; `tasks clear-focus` removes it. Replacing focus selects an existing Task rather than creating or canceling one.
-
-Continuation is single-flight and bounded to 20 automatic turns or 6 unchanged Task snapshots. Reaching either bound persists a paused focus and records the reason in append-only Task history. Human input resumes only these automatically paused focuses; an explicit user pause remains paused.
-
-Checklist criteria are an item-to-proof map. Every new item requires one or more typed references to inspectable evidence; proof presence does not imply that the evidence passed an executable gate:
-
-```ts
-checklist: {
-  "Write failing skill-row tests": {
-    proof: [
-      { type: "file", target: "test/frontends.test.ts" },
-      { type: "symbol", target: "test/frontends.test.ts#skill row test" }
-    ]
-  }
-}
-```
-
-Proof types are `file`, `symbol`, `code`, `test`, `command`, `artifact`, and `url`. Existing array checklists remain readable as legacy items with `proof: missing`; Papyrus does not invent evidence.
-
-Papyrus also injects an Alef-style reconciliation block at `before_agent_start` while work remains: `Current`, `Desired`, `Verify`, and `Next`. The agent is explicitly instructed to ask **“Did we accomplish this task?”** and run review before marking it done. The injection disappears when every task is done or canceled.
-
-After assembling each system-prompt addition, Papyrus emits a versioned `papyrus.context-injection.v1` observation on Pi's shared extension event bus. It contains only exact byte/character sizes, Rule count, a labeled token estimate, prompt share, sequence, and a SHA-256 payload fingerprint; Rule/Task text, prompts, project paths, and credentials are never included. Jittor can persist and assess these observations without Papyrus maintaining a second telemetry store.
-
-Task edits mutate the existing Papyrus-owned Task identity and append an `updated` event; title, body, and labels can be revised without canceling the Task or creating a replacement. Lifecycle, relationships, gates, checklist metadata, scope, and focus remain intact. The same `update` action provides a narrowly guarded recovery for Tasks accidentally created terminal by a legacy default: `status=todo` requires an audit reason, cannot be combined with content edits, only applies when `created` is the sole lifecycle event, and appends `creation_recovered` rather than rewriting history.
-
-## Why
-
-Papyrus keeps SQLite’s local simplicity while centralizing writes, migrations, lifecycle invariants, gate execution, and maintenance in one small supervised process. The loopback bearer token prevents unrelated local HTTP callers from mutating the graph, while the native Pi extension provides richer domain tools and TUI integration.
-
-## Install
-
-Install the published Pi package, then install its supervised user service:
-
-```bash
-packed install npm:@danypops/papyrus
-~/.pi/agent/npm/node_modules/.bin/papyrus service install
-```
-
-Existing databases are never migrated on daemon boot. After upgrading to a newer schema, run the authenticated CLI migration explicitly. Older databases receive prerequisite schemas—including Task continuation and Context Mesh extensions—in one transaction. Existing Tasks are deliberately marked **unscoped**: Papyrus does not guess ownership from titles, labels, historical cwd, or repository names. They remain visible in **All projects** until explicitly assigned with `papyrus tasks assign-project <task-id> [project-root]`:
-
-```bash
-~/.pi/agent/npm/node_modules/.bin/papyrus migrate schema
-```
-
-Until that command succeeds, health reports `migrationRequired` and normal domain operations are rejected with actionable guidance. Migration is not exposed as a Pi tool or MCP action. New empty databases bootstrap directly at the current schema.
-
-Reload Pi once the service is active. Git installs remain available for development builds:
-
-```bash
-packed install git:github.com/DanyPops/papyrus
-```
+`src/index.ts` is this package's public surface for `@danypops/pi-papyrus` (and any other real npm consumer): explicit, named exports only, not a blanket re-export of internal daemon plumbing.

package/package.json

@@ -1,9 +1,11 @@
 {
   "name": "@danypops/papyrus",
-  "version": "0.34.3",
+  "version": "0.35.1",
   "description": "Daemon-backed graph artifacts, evidence-bearing tasks, rules, skills, and native TUI workflows for Pi",
   "type": "module",
   "keywords": ["pi-package"],
+  "main": "./src/index.ts",
+  "types": "./src/index.ts",
   "bin": {
     "papyrus": "src/cli.ts"
   },
@@ -12,25 +14,16 @@
     "typecheck": "tsc --noEmit -p tsconfig.json",
     "cli": "bun src/cli.ts",
     "serve": "bun src/cli.ts serve",
-    "service:install": "bun src/cli.ts service install",
-    "guard:install": "git config core.hooksPath .githooks"
-  },
-  "pi": {
-    "extensions": ["extension/src/index.ts"]
-  },
-  "peerDependencies": {
-    "@earendil-works/pi-coding-agent": "*",
-    "@earendil-works/pi-tui": "*",
-    "typebox": "*"
+    "service:install": "bun src/cli.ts service install"
   },
   "devDependencies": {
-    "@earendil-works/pi-coding-agent": "^0.80.10",
     "bun-types": "latest",
     "typescript": "^5.7.3"
   },
   "repository": {
     "type": "git",
-    "url": "git+https://github.com/DanyPops/papyrus.git"
+    "url": "git+https://github.com/DanyPops/papyrus.git",
+    "directory": "packages/papyrus"
   },
   "homepage": "https://github.com/DanyPops/papyrus#readme",
   "bugs": {
@@ -39,9 +32,8 @@
   "publishConfig": {
     "access": "public"
   },
-  "files": ["src", "extension", "README.md"],
+  "files": ["src", "README.md"],
   "dependencies": {
-    "beautiful-mermaid": "1.1.3",
-    "@danypops/daemon-kit": "^0.4.0"
+    "@danypops/daemon-kit": "^0.10.0"
   }
 }

package/src/index.ts

@@ -0,0 +1,32 @@
+/**
+ * Public surface for @danypops/pi-papyrus (and any other real npm consumer): every type or
+ * value the Pi extension package needs across the package boundary, named explicitly rather
+ * than a blanket `export *` on service-heavy modules -- matches ports-and-adapters practice of a
+ * purposeful API, not "everything happens to be reachable."
+ */
+export * from "./constants.ts";
+
+export type { Artifact, ArtifactEdge } from "./domain/artifact.ts";
+export { PROOF_TYPES, checklistEntries, type ProofReference } from "./domain/checklist.ts";
+export { DISCUSSION_SUBTYPE, readDiscussionExtra, type DiscussionRound } from "./domain/discussion.ts";
+export type { DisplayGraph, DisplayGraphEdge, DisplayGraphNode, RenderedGraph } from "./domain/display-graph.ts";
+export type { GateResult } from "./domain/gate.ts";
+export type { NoteHistoryPage } from "./domain/note-event.ts";
+export type { TaskEvent, TaskHistoryPage } from "./domain/task-event.ts";
+export type { TaskLease } from "./domain/task-lease.ts";
+export type { TaskViewSelection } from "./domain/task-scope.ts";
+
+export type { ArtifactStore } from "./ports/artifact-store.ts";
+export type { GraphRenderer } from "./ports/graph-renderer.ts";
+
+export { connectPapyrusClient, type PapyrusClient } from "./client.ts";
+export type { DiscussionAndRounds } from "./discussion-service.ts";
+export { NOTE_DISPOSITIONS } from "./note-service.ts";
+export type { OperationName, SchemaState } from "./service.ts";
+export type { SkillWorkflowRunResult } from "./skill-execution.ts";
+export { projectArtifactRelationships } from "./artifact-relationship-view.ts";
+export { taskContext } from "./task-context.ts";
+export { projectTaskExecution, type TaskExecutionPlan, type TaskExecutionState } from "./task-execution.ts";
+export { projectTaskGraph, type TaskGraphView } from "./task-graph-view.ts";
+export { fallbackLabel, projectTaskRelationships } from "./task-relationship-view.ts";
+export type { TaskCompletion, TaskGraph, TaskNode, TaskStatus } from "./task-service.ts";

package/src/modules/discuss.ts

@@ -12,10 +12,15 @@ type OperationInput = Record<string, unknown>;
 
 function string(input: OperationInput, key: string): string {
 	const value = input[key];
-	if (typeof value !== "string" || value.length === 0) throw new Error(`${key} is required`);
+	if (typeof value !== "string" || value.length === 0) throw new Error(`${key} is required${REQUIRED_FIELD_HINTS[key] ? ` (${REQUIRED_FIELD_HINTS[key]})` : ""}`);
 	return value;
 }
 
+/** Fields whose name alone doesn't say what a valid value looks like -- everything else (title, content, id, settlement) is self-explanatory. */
+const REQUIRED_FIELD_HINTS: Record<string, string> = {
+	actor: 'a display name for who is posting, e.g. "alice" or "agent"',
+};
+
 function optionalString(input: OperationInput, key: string): string | undefined {
 	const value = input[key];
 	if (value === undefined) return undefined;

package/extension/src/active-task-continuation.ts

@@ -1,131 +0,0 @@
-export interface ActiveTaskMarker {
-	id: string;
-	title: string;
-	updated_at: string;
-}
-
-export interface ActiveTaskContinuationOptions {
-	maxTurns: number;
-	maxUnchangedTurns: number;
-}
-
-export interface ActiveTaskContinuationState {
-	queued: boolean;
-	consecutiveTurns: number;
-	unchangedTurns: number;
-	pausedReason?: string;
-}
-
-export interface ActiveTaskContinuationDecision {
-	action: "continue" | "wait" | "pause";
-	reason: string;
-	prompt?: string;
-}
-
-const TITLE_LIMIT = 120;
-const AUTOMATIC_PAUSE_PREFIX = "automatic continuation paused:";
-
-export function automaticPauseReason(reason: string): string {
-	return `${AUTOMATIC_PAUSE_PREFIX} ${reason}`;
-}
-
-export function shouldResumeFocusOnHumanInput(status: string, pauseReason?: string): boolean {
-	return status === "paused" && pauseReason?.startsWith(AUTOMATIC_PAUSE_PREFIX) === true;
-}
-
-function fingerprint(task: ActiveTaskMarker): string {
-	return `${task.id}:${task.updated_at}`;
-}
-
-function continuationPrompt(task: ActiveTaskMarker): string {
-	return [
-		"Continue the active Papyrus Task now; do not hand off merely because the previous Pi run settled.",
-		"Reconcile its lifecycle, take the next concrete action, use tools, submit it for review when implementation effort is ready, and run gates plus checklist review before completion.",
-		"Do not shrink the task's scope to whatever fits in this turn, and do not treat a status update or summary as a substitute for doing the work or as proof of completion.",
-		"If something blocks progress, do not reject or pause on the first obstacle -- only after it genuinely recurs, and only when the task truly cannot proceed without external input.",
-		`Active task: ${task.title.slice(0, TITLE_LIMIT)}`,
-	].join("\n");
-}
-
-export class ActiveTaskContinuation {
-	private queued = false;
-	private consecutiveTurns = 0;
-	private unchangedTurns = 0;
-	private lastFingerprint: string | undefined;
-	private pausedReason: string | undefined;
-
-	constructor(private readonly options: ActiveTaskContinuationOptions) {
-		if (!Number.isInteger(options.maxTurns) || options.maxTurns < 1) throw new Error("maxTurns must be a positive integer");
-		if (!Number.isInteger(options.maxUnchangedTurns) || options.maxUnchangedTurns < 1) {
-			throw new Error("maxUnchangedTurns must be a positive integer");
-		}
-	}
-
-	evaluate(task: ActiveTaskMarker | null, context: { idle: boolean; pendingMessages: boolean }): ActiveTaskContinuationDecision {
-		if (!context.idle) return { action: "wait", reason: "Pi is not settled" };
-		if (context.pendingMessages) return { action: "wait", reason: "Pi already has pending messages" };
-		if (this.queued) return { action: "wait", reason: "continuation already queued" };
-		if (!task) {
-			this.resetProgress();
-			return { action: "wait", reason: "no active task" };
-		}
-
-		const currentFingerprint = fingerprint(task);
-		if (currentFingerprint !== this.lastFingerprint) {
-			this.lastFingerprint = currentFingerprint;
-			this.unchangedTurns = 0;
-			this.pausedReason = undefined;
-		} else {
-			this.unchangedTurns += 1;
-		}
-
-		if (this.consecutiveTurns >= this.options.maxTurns) {
-			return this.pause(`automatic turn limit reached (${this.options.maxTurns})`);
-		}
-		if (this.unchangedTurns >= this.options.maxUnchangedTurns) {
-			return this.pause(`no task progress after ${this.options.maxUnchangedTurns} automatic turns`);
-		}
-
-		this.queued = true;
-		this.consecutiveTurns += 1;
-		return {
-			action: "continue",
-			reason: "an active task remains",
-			prompt: continuationPrompt(task),
-		};
-	}
-
-	onAgentStart(): void {
-		this.queued = false;
-	}
-
-	onCompaction(): void {
-		this.queued = false;
-	}
-
-	onHumanInput(): void {
-		this.resetProgress();
-	}
-
-	status(): ActiveTaskContinuationState {
-		return {
-			queued: this.queued,
-			consecutiveTurns: this.consecutiveTurns,
-			unchangedTurns: this.unchangedTurns,
-			...(this.pausedReason ? { pausedReason: this.pausedReason } : {}),
-		};
-	}
-
-	private pause(reason: string): ActiveTaskContinuationDecision {
-		this.pausedReason = reason;
-		return { action: "pause", reason };
-	}
-
-	private resetProgress(): void {
-		this.queued = false;
-		this.consecutiveTurns = 0;
-		this.unchangedTurns = 0;
-		this.lastFingerprint = undefined;
-		this.pausedReason = undefined;
-	}
-}