@telora/daemon 0.17.46 → 0.17.48

package/build-info.json

@@ -1,6 +1,6 @@
 {
-  "commitSha": "efd644f3",
-  "builtAt": "2026-06-11T20:41:25.356Z",
+  "commitSha": "521368d0",
+  "builtAt": "2026-06-11T22:45:20.530Z",
   "expectedMigrations": [
     "20250829113330_create_org_nodes_table.sql",
     "20250829113402_fix_function_security_search_path.sql",

package/dist/templates/claude-md.d.ts

@@ -29,7 +29,7 @@ export declare const TELORA_CLAUDE_MD_END = "<!-- END TELORA SEED -->";
  * For Codex: the MCP server is registered in `~/.codex/config.toml` (global).
  */
 export declare const SEED_MCP_REGISTRATION_SENTENCE = "The Telora MCP server is registered in `.mcp.json`.";
-export declare const SEED_BODY = "# Telora workstation context\n\nThis repo is connected to Telora -- a differential control plane for\nsoftware delivery. Intent and reality are paired signals; the meaningful\nwork happens at the difference.\n\n## Before you write any code (read this first)\n\nDEFAULT: on a Telora-connected workstation, a new capability starts as\n**declared intent** before any code. When the user says \"I want to build\nX\", your first move is NOT to scaffold X -- it is to declare it: create\n(or select) a Focus -> delivery -> issue and move an issue to **In\nProgress**. Code is written only after intent is anchored above it.\n\nThis polarity is deliberate and easy to get backwards. Building directly\nin the working tree -- scaffolding, installing dependencies, starting a\ndev server, writing application files -- is the **exception**, taken ONLY\nwhen the user explicitly asks for it. Recognized bypass phrases:\n\"build locally\", \"just write it\", \"skip Telora\", \"don't track this\",\n\"throwaway\". Absent an explicit signal like these, treat any build\nrequest as a request to declare intent in Telora first.\n\nAsking good clarifying questions about stack, scope, or dependencies is\nNOT a substitute for this step -- that is execution-layer scoping, and it\ncomes *after* the capability is declared, not instead of it. Scoping is\nagent work; declaring that a capability matters is the part that must\nland in Telora first.\n\n**Surface the fork; do not silently pick it.** The common failure is\nresolving an ambiguous request toward the path of least resistance --\ne.g. reading \"a web app I run locally on my LAN\" (a deployment target) as\n\"build locally\" (skip Telora). When intent is not already explicit, your\nFIRST response to a build request names the choice rather than assuming\nit: \"I'll scope this in Telora unless you want it built locally -- which?\"\nOne question, once, at the start. Let the user pick; never pick for them\nby starting to type code.\n\n**First action rule.** On a build / new-capability request, your first\ntool call is a Telora planning call (telora_product_focus / _delivery /\n_issue) OR the fork question above -- never Write, Edit, or a code-running\nBash command. If the first move cannot be code, building-before-intent\ncannot happen.\n\nWhy: an artifact with no declared intent above it is reality moving with\nnothing to measure it against -- pure noise to the differential loop. The\nwhole system is built to compute intent-minus-reality; code that skips\nthe intent half defeats the instrument.\n\n## Planning hierarchy\n\n- **Focus** = one capability. All phases of building one thing belong\n  in one focus. Focuses are not phases; if a focus looks like a\n  phase, consolidate it.\n- **Delivery** = a shippable phase or major component of a capability.\n- **Context Group** = optional grouping of related issues that share\n  meaningful context (relevant files, architectural notes). A CG earns its\n  existence by carrying context, not by being a folder.\n- **Task** = one discrete implementable unit. Bounded files, focused\n  session. Multiple \"and\" clauses across different concerns means split.\n\nScope by purpose, not count. The right number of deliveries is however\nmany phases the work naturally has.\n\n## PRD: \"build a working app in one run\"\n\nA **PRD** sits one altitude above Focus (Product -> PRD -> Focus): a\nbounded, verifiable, retire-able milestone carrying a **Prerequisite Tree**\nof `goal` / `obstacle` / `overcome` nodes. Each `overcome` materializes\nas a focus; the daemon progressively arms the **frontier** of foci as\nupstream obstacles clear. This is the entry point a user means by \"build a\nfully working app in one go.\"\n\nIt is NOT big-bang generation: you author the tree once, commit a path,\nand the differential loop walks the frontier to completion -- the execution\nunderneath is still the normal focus -> delivery -> issue + review loop.\n\nThe PRD tools are **lazy-loaded** -- they do not exist until you load the\ndomain. If you don't see `telora_prd` / `telora_prd_tree`, run:\n\n```\ntelora_discover { action: \"load\", domain: \"prd\" }\n```\n\nThen: `telora_prd` create (referencing a Vision) -> `telora_prd_tree`\nauthor nodes (obstacles carry a verifiable `clearancePredicate`) + edges ->\ncommit a pathway -> `materialize_overcome` each into a focus -> arm the\ndaemon PRD loop. All authoring is harness+MCP; there is no Telora authoring UI.\n\n## Issue workflow\n\n`To Do` -> `In Progress` -> `In Review` / `Blocked` -> `Done`.\n\nIssue types: **Context Group**, **Task**, **Bug**.\n\nMovement rules:\n\n- An issue MUST be set to `In Progress` before any work begins on it.\n- Never skip `In Progress`. Never move directly from `To Do` to `Done`.\n- Set status with `telora_product_issue` action=update.\n\nDelivery and focus stages advance automatically based on issue\nactivity. Agents never set delivery executionStatus directly.\n\n## MCP tool surface (what's available in this session)\n\nThe Telora MCP server is registered in `.mcp.json`. Core tool families:\n\n- `telora_product` -- list/get/create/update products\n- `telora_product_focus` -- focuses under a product\n- `telora_product_delivery` -- deliveries under a focus\n- `telora_product_issue` -- issues (Context Groups, Tasks, Bugs) under a delivery\n- `telora_agent` -- agent roles, escalation requests\n- `telora_loop_*` -- loop documents, questions, answers\n- `telora_discover` -- on-demand registration of deferred tool domains\n\nResolve the live tool list at runtime via `telora_discover` rather than\nhard-coding a list that drifts.\n\n## Human-vs-agent boundaries\n\n- Humans own **intent** and **completion**.\n  - Intent: what capability matters, what changes when. Pre-handoff.\n  - Completion: closing the loop on whether a focus is done. Post-handoff.\n- Agents own **scoping** and **execution**.\n  - Scoping: decomposing a focus into deliveries, deliveries into\n    issues, restructuring mid-flight as the agent learns more.\n  - Execution: writing code, running tests, committing, reporting.\n\nDo not ask humans for operational details they expect the agent to figure\nout. Do not silently complete a focus on the human's behalf. Escalate\nwhen stuck via `telora_agent` action=escalate.\n\n## Differential signaling\n\nTelora is asymmetric: it moves reality toward intent, never the reverse.\nAgents do not lower the bar to make signals look better -- they escalate.\nEvery artifact (commit, work summary, gate result) is signal toward the\ndeclared intent; raw activity without intent reduction is noise.\n\nA short corrective comment from the user is high-signal -- treat brief\npushback as the most important input in the session.\n\n## Workflows and policies\n\n- **Workflow**: stage directives shape agent behavior at discrete\n  transitions. What context the agent sees (assembly recipes), what tools\n  it can use, how it thinks (prompt + model). Live in Telora's\n  `workflow_stages.agent_directive` JSONB.\n- **Policy** (organizational, deferred): cross-cutting constraints that\n  feed into stage directives.\n\nWhen you cross a stage transition, the daemon may inject context or spawn\na fresh sub-agent per the directive. Don't override that flow without a\nclear reason.\n";
+export declare const SEED_BODY = "# Telora workstation context\n\nThis repo is connected to Telora -- a differential control plane for\nsoftware delivery. Intent and reality are paired signals; the meaningful\nwork happens at the difference.\n\n## Before you write any code (read this first)\n\nDEFAULT: on a Telora-connected workstation, a new capability starts as\n**declared intent** before any code. When the user says \"I want to build\nX\", your first move is NOT to scaffold X -- it is to declare it: create\n(or select) a Focus -> delivery -> issue and move an issue to **In\nProgress**. Code is written only after intent is anchored above it.\n\nThis polarity is deliberate and easy to get backwards. Building directly\nin the working tree -- scaffolding, installing dependencies, starting a\ndev server, writing application files -- is the **exception**, taken ONLY\nwhen the user explicitly asks for it. Recognized bypass phrases:\n\"build locally\", \"just write it\", \"skip Telora\", \"don't track this\",\n\"throwaway\". Absent an explicit signal like these, treat any build\nrequest as a request to declare intent in Telora first.\n\nAsking good clarifying questions about stack, scope, or dependencies is\nNOT a substitute for this step -- that is execution-layer scoping, and it\ncomes *after* the capability is declared, not instead of it. Scoping is\nagent work; declaring that a capability matters is the part that must\nland in Telora first.\n\n**Surface the fork; do not silently pick it.** The common failure is\nresolving an ambiguous request toward the path of least resistance --\ne.g. reading \"a web app I run locally on my LAN\" (a deployment target) as\n\"build locally\" (skip Telora). When intent is not already explicit, your\nFIRST response to a build request names the choice rather than assuming\nit: \"I'll scope this in Telora unless you want it built locally -- which?\"\nOne question, once, at the start. Let the user pick; never pick for them\nby starting to type code.\n\n**First action rule.** On a build / new-capability request, your first\ntool call is a Telora planning call (telora_product_focus / _delivery /\n_issue) OR the fork question above -- never Write, Edit, or a code-running\nBash command. If the first move cannot be code, building-before-intent\ncannot happen.\n\nWhy: an artifact with no declared intent above it is reality moving with\nnothing to measure it against -- pure noise to the differential loop. The\nwhole system is built to compute intent-minus-reality; code that skips\nthe intent half defeats the instrument.\n\n## Planning hierarchy\n\n- **Focus** = the context that defines an area of work -- not \"one\n  capability.\" All phases of building within that area belong in one\n  focus; if a \"focus\" is really just one phase, fold it back in.\n- **Delivery** = a shippable phase or major component of a capability.\n- **Context Group** = optional grouping of related issues that share\n  meaningful context (relevant files, architectural notes). A CG earns its\n  existence by carrying context, not by being a folder.\n- **Task** = one discrete implementable unit. Bounded files, focused\n  session. Multiple \"and\" clauses across different concerns means split.\n\nScope by purpose, not count. The right number of deliveries is however\nmany phases the work naturally has.\n\n## PRD: \"build a working app in one run\"\n\nA **PRD** sits one altitude above Focus (Product -> PRD -> Focus): a\nbounded, verifiable, retire-able milestone carrying a **Prerequisite Tree**\nof `goal` / `obstacle` / `overcome` nodes. Each `overcome` materializes\nas a focus; the daemon progressively arms the **frontier** of foci as\nupstream obstacles clear. This is the entry point a user means by \"build a\nfully working app in one go.\"\n\nIt is NOT big-bang generation: you author the tree once, commit a path,\nand the differential loop walks the frontier to completion -- the execution\nunderneath is still the normal focus -> delivery -> issue + review loop.\n\nThe PRD tools are **lazy-loaded** -- they do not exist until you load the\ndomain. If you don't see `telora_prd` / `telora_prd_tree`, run:\n\n```\ntelora_discover { action: \"load\", domain: \"prd\" }\n```\n\nThen: `telora_prd` create (referencing a Vision) -> `telora_prd_tree`\nauthor nodes (obstacles carry a verifiable `clearancePredicate`) + edges ->\ncommit a pathway -> `materialize_overcome` each into a focus -> arm the\ndaemon PRD loop. All authoring is harness+MCP; there is no Telora authoring UI.\n\n## Issue workflow\n\n`To Do` -> `In Progress` -> `In Review` / `Blocked` -> `Done`.\n\nIssue types: **Context Group**, **Task**, **Bug**.\n\nMovement rules:\n\n- An issue MUST be set to `In Progress` before any work begins on it.\n- Never skip `In Progress`. Never move directly from `To Do` to `Done`.\n- Set status with `telora_product_issue` action=update.\n\nDelivery and focus stages advance automatically based on issue\nactivity. Agents never set delivery executionStatus directly.\n\n## MCP tool surface (what's available in this session)\n\nThe Telora MCP server is registered in `.mcp.json`. Core tool families:\n\n- `telora_product` -- list/get/create/update products\n- `telora_product_focus` -- focuses under a product\n- `telora_product_delivery` -- deliveries under a focus\n- `telora_product_issue` -- issues (Context Groups, Tasks, Bugs) under a delivery\n- `telora_agent` -- agent roles, escalation requests\n- `telora_loop_*` -- loop documents, questions, answers\n- `telora_discover` -- on-demand registration of deferred tool domains\n\nResolve the live tool list at runtime via `telora_discover` rather than\nhard-coding a list that drifts.\n\n## Human-vs-agent boundaries\n\n- Humans own **intent** and **completion**.\n  - Intent: what capability matters, what changes when. Pre-handoff.\n  - Completion: closing the loop on whether a focus is done. Post-handoff.\n- Agents own **scoping** and **execution**.\n  - Scoping: decomposing a focus into deliveries, deliveries into\n    issues, restructuring mid-flight as the agent learns more.\n  - Execution: writing code, running tests, committing, reporting.\n\nDo not ask humans for operational details they expect the agent to figure\nout. Do not silently complete a focus on the human's behalf. Escalate\nwhen stuck via `telora_agent` action=escalate.\n\n## Differential signaling\n\nTelora is asymmetric: it moves reality toward intent, never the reverse.\nAgents do not lower the bar to make signals look better -- they escalate.\nEvery artifact (commit, work summary, gate result) is signal toward the\ndeclared intent; raw activity without intent reduction is noise.\n\nA short corrective comment from the user is high-signal -- treat brief\npushback as the most important input in the session.\n\n## Workflows and policies\n\n- **Workflow**: stage directives shape agent behavior at discrete\n  transitions. What context the agent sees (assembly recipes), what tools\n  it can use, how it thinks (prompt + model). Live in Telora's\n  `workflow_stages.agent_directive` JSONB.\n- **Policy** (organizational, deferred): cross-cutting constraints that\n  feed into stage directives.\n\nWhen you cross a stage transition, the daemon may inject context or spawn\na fresh sub-agent per the directive. Don't override that flow without a\nclear reason.\n";
 /**
  * Render a fresh-repo CLAUDE.md.
  *

package/dist/templates/claude-md.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"claude-md.d.ts","sourceRoot":"","sources":["../../src/templates/claude-md.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;GAYG;AAEH,eAAO,MAAM,sBAAsB,+BAA+B,CAAC;AACnE,eAAO,MAAM,oBAAoB,6BAA6B,CAAC;AAE/D;;;;;;GAMG;AACH;;;;;;;GAOG;AACH,eAAO,MAAM,8BAA8B,wDACY,CAAC;AAExD,eAAO,MAAM,SAAS,+nOA0JrB,CAAC;AAEF;;;;;;GAMG;AACH,wBAAgB,cAAc,CAAC,WAAW,EAAE,MAAM,GAAG,IAAI,GAAG,MAAM,CASjE"}
+{"version":3,"file":"claude-md.d.ts","sourceRoot":"","sources":["../../src/templates/claude-md.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;GAYG;AAEH,eAAO,MAAM,sBAAsB,+BAA+B,CAAC;AACnE,eAAO,MAAM,oBAAoB,6BAA6B,CAAC;AAE/D;;;;;;GAMG;AACH;;;;;;;GAOG;AACH,eAAO,MAAM,8BAA8B,wDACY,CAAC;AAExD,eAAO,MAAM,SAAS,6qOA0JrB,CAAC;AAEF;;;;;;GAMG;AACH,wBAAgB,cAAc,CAAC,WAAW,EAAE,MAAM,GAAG,IAAI,GAAG,MAAM,CASjE"}

package/dist/templates/claude-md.js

@@ -79,9 +79,9 @@ the intent half defeats the instrument.
 
 ## Planning hierarchy
 
-- **Focus** = one capability. All phases of building one thing belong
-  in one focus. Focuses are not phases; if a focus looks like a
-  phase, consolidate it.
+- **Focus** = the context that defines an area of work -- not "one
+  capability." All phases of building within that area belong in one
+  focus; if a "focus" is really just one phase, fold it back in.
 - **Delivery** = a shippable phase or major component of a capability.
 - **Context Group** = optional grouping of related issues that share
   meaningful context (relevant files, architectural notes). A CG earns its

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@telora/daemon",
-  "version": "0.17.46",
+  "version": "0.17.48",
   "description": "Agent orchestration daemon for Telora - spawns and manages Claude Code instances",
   "type": "module",
   "bin": {