@lambdacurry/arbor 0.23.17 → 0.23.19

package/dist/arbor.js

@@ -2,7 +2,7 @@
 // package.json
 var package_default = {
   name: "@lambdacurry/arbor",
-  version: "0.23.17",
+  version: "0.23.19",
   description: "The Arbor CLI — a shared workspace for people and agents. The human + headless-agent write path over Arbor's guarded operation surface.",
   keywords: [
     "agents",
@@ -7982,7 +7982,8 @@ var COMPUTER_RUN_F1_FINAL_FAILURE_CODES = new Set([
   "run.provision.reconciliation_failed",
   "run.provision.owner_unavailable",
   "run.provision.provider_unavailable",
-  "run.provision.placement_unserviceable"
+  "run.provision.placement_unserviceable",
+  "run.provision.abandoned"
 ]);
 var TERMINAL = new Set(["finished", "failed", "cancelled"]);
 var RUN_LIFECYCLE_TYPES = new Set(["run.started", "run.finished", "run.failed", "run.cancelled"]);
@@ -10050,7 +10051,8 @@ function compactTldrawPreview(value) {
         "height",
         "size"
       ])
-    ]
+    ],
+    ["renderInProgress", selected(preview.renderInProgress, ["leaseExpiresAt"])]
   ]);
 }
 function omitNull(value) {
@@ -10731,6 +10733,8 @@ var CONTRIBUTION_ADD_LINK_RELS = [
   "delivered-by"
 ];
 var ARBOR_FEEDBACK_GUIDANCE = `ARBOR-SPECIFIC FEEDBACK — File ONE bounded report through \`contribute_arbor_feedback\` when Arbor itself caused meaningful friction: confusing semantics; surprising Arbor UI/MCP/CLI behavior; a missing Arbor capability; repeated Arbor retries; an Arbor-specific workaround; or misleading state, recovery guidance, or ergonomics. Usually do NOT report an ordinary repository bug, a routine GitHub/Cloudflare/provider failure Arbor did not cause or obscure, your own mistake, or generic implementation difficulty. One incident = one report: use one stable idempotencyKey to retry that same logical submission rather than reporting every participating call. Never include raw prompts/transcripts, shell output, command contents, secrets, provider payloads, or arbitrary error dumps. For this filing, \`type: friction\` is input shorthand for \`critique\`; the stored and shared Contribution type remains \`critique\`. The report lands as its own visible shared Feedback Thread as submitted; the fbk receipt and reviewer-only metadata remain private. \`feedback_status\` reads only a receipt you own, while \`feedback_tree\` → \`feedback_recall\` → \`feedback_thread_get\` browses the shared forum.`;
+var CONTRIBUTION_BODY_GUIDANCE = "Write for a newcomer: plain statement first, evidence after; say what any id, code, or coined term IS before using it; end with what you need, or that nothing is. Artifact refs on their own line render as preview cards.";
+var CONTRIBUTION_SUMMARY_GUIDANCE = "one plain sentence a new hire could repeat — what changed and why it matters, not a changelog of codes, ids, and arrows (HARD LIMIT 500 characters; rejected past it)";
 var ORIENTATION = `Arbor is your team's deliberation room and shared memory — people and agents settle typed work here, and Arbor remembers what's decided. To work well:
 
 ${ARBOR_FEEDBACK_GUIDANCE}
@@ -10740,7 +10744,7 @@ Arbor's MCP is the collaboration and durable-knowledge surface. Configure, autho
 HUMAN-FACING LINKS — When communicating an Arbor object to a human, prefer the human-facing clickable URL Arbor returned. Keep raw IDs primarily for tool calls, debugging, exact references, and agent-to-agent handoffs. Never invent or manually construct Arbor URLs.
 
 1. RECALL FIRST — but Arbor is MEMORY, NOT TRUTH. Run \`recall\` before re-deriving or restating anything — it may already be settled; cite prior work ([label](#con_…)) and build on it. Phrase the query in PROBLEM-LANGUAGE (a natural-language question — "how do agents handle X"), not extracted keywords; it ranks better. Empty recall is itself worth noting. In a large Space, don't search the whole org by habit: use \`tree\` to choose the room, then scope \`recall\` with \`space\`/\`topic\`/\`thread\` before deeper reads. External tree reads page four roots; follow \`nextCursor\`, use \`all=true\` only for deliberate complete enumeration, and scope \`depth=threads\` to one Space or Topic. On that map, \`activeThreadCount\` is the current working set (active/stuck/needs-review/standing), while \`status\` is the Topic attention rollup: \`stuck\` means any stuck Thread; \`attention\` means needs-review or an open request; \`healthy\` means neither. A contribution records what was true when it was WRITTEN, so before you assert the CURRENT state of anything outside Arbor — a PR, a build, a deploy, a config — check the live source; another contribution is not evidence of the present, and neither is a local copy of something whose home is elsewhere. And when you DO check, post the RECEIPT with the claim (AD-209): attach the actual output/screenshot (an attached file becomes a durable artifact carrying who-captured-it and when, citable as #art_… forever) or name exactly what you checked and when ("CI run #841, green, checked just now") — a "verified" with no receipt is a claim the next reader must take on faith or re-derive. When a receipted claim has AGED and matters again, don't re-trust it and don't silently re-argue it: \`request\` a re-check ("re-run this check"), and whoever runs it answers through the request with fresh evidence. WHY: a room where everyone re-derives is just a chat log — but a room that mistakes its own memory for the world confidently reports blockers that no longer exist, and this week's failures were exactly that: stale claims re-asserted as current because nothing distinguished a receipted observation from confident prose. And orient to the ROOM the way you orient to the record: \`tree\` is the map AND the way in — it carries each room's \`lanesForYou\`, the durable contribution lanes that match what you said you do; follow one into \`space_get\`/\`topic_get\`, where the room's purpose, guidance, goals, and full lane list live. A lane is an invitation, never an obligation: what you OWE is only ever in \`inbox\`.
-2. CONTRIBUTE typed points — but ADD ONLY WHAT'S ADDITIVE (AD-205). Ask what the most additive move is, not whether to say something: if your reaction to a point already on the record fits in one line — agree OR disagree — STAMP it (vouch, or push back with a one-line why), don't restate it; if you'd only echo consensus, reviewing IS the contribution and staying out is fine. When you DO contribute, it's ONE point, with the type that names your move (proposal / critique / question / evidence / risk / correction / assertion / decision). Markdown welcome; put references IN your prose (a URL or [label](#con_…) becomes a navigable reference). Prose refs are CITATIONS — they never move your contribution in the thread, so cite freely; to REPLY under a specific contribution, pass links: [{rel: 'inReplyTo', targetId}] (AD-196). WHY: a thread where every agent restates the consensus is noise — the record is strongest when each point appears ONCE and gets vouched (or contested) with a stamp, not re-said; and one typed point is reviewable on its own, so a synthesis citing five points should read as the most top-level thing in the thread, not as a reply to the first one it mentions.
+2. CONTRIBUTE typed points — but ADD ONLY WHAT'S ADDITIVE (AD-205). Ask what the most additive move is, not whether to say something: if your reaction to a point already on the record fits in one line — agree OR disagree — STAMP it (vouch, or push back with a one-line why), don't restate it; if you'd only echo consensus, reviewing IS the contribution and staying out is fine. When you DO contribute, it's ONE point, with the type that names your move (proposal / critique / question / evidence / risk / correction / assertion / decision). Write so a teammate reading only your post can tell what happened, why it matters, and what's next. Markdown welcome; put references IN your prose (a URL or [label](#con_…) becomes a navigable reference). Prose refs are CITATIONS — they never move your contribution in the thread, so cite freely; to REPLY under a specific contribution, pass links: [{rel: 'inReplyTo', targetId}] (AD-196). WHY: a thread where every agent restates the consensus is noise — the record is strongest when each point appears ONCE and gets vouched (or contested) with a stamp, not re-said; and one typed point is reviewable on its own, so a synthesis citing five points should read as the most top-level thing in the thread, not as a reply to the first one it mentions. People who weren't in your session read these threads too; shorthand that only the agents in the loop understand shuts them out.
 3. ANSWER through requests. When \`inbox\` or a thread shows an open request you can meet, answer THROUGH it — \`respond\` to it, or \`stamp\` the contribution a review request is about — so it completes and the requester is notified. WHY: a plain reply that merely happens to answer leaves their request hanging (the most common failure). Requests are what you OWE; the Threads you are RESPONSIBLE for moving are \`thread_list\` (assign yourself or a teammate with \`thread_assign\` when responsibility is real, not to delegate one action — that is a request).
 4. REVIEW honestly; promote the standout, sparingly. \`stamp\` to vouch or push back with a one-line why (you can't stamp your own work — request a review via \`request\`). PROMOTE a contribution/artifact only when it's the standout the org should find FIRST (the \uD83C\uDF96️). One deliberate exception (AD-200): in a STANDING thread, periodically promoting a distilling synthesis IS the job — it's how an open-forever lane compresses for newcomers and recall, not applause inflation; promoting your own synthesis there is fine (only stamps bar self-review). WHY: promotion is curation, not applause — and it's about an OUTPUT, never a whole thread (a thread RESOLVES; it is never "promoted").
 5. EDIT, don't repost. \`edit\` your own contribution to sharpen it; the record stays audited. A genuinely different point is a NEW contribution.
@@ -11201,16 +11205,16 @@ var ACTION_DEFINITIONS = [
   {
     name: "contribute",
     title: "Contribute to a thread",
-    description: "Add one genuinely additive typed contribution to a Thread; use stamp for one-line agreement/disagreement and respond or mark_as_response for requests, while prose refs stay citations and links create deliberate reply/contest edges. For Computer media evidence, place the attachments[].markdown returned by computer_verify or computer_export in the body and pass attachmentIds; put Artifact refs on their own line for preview cards, and an attachment not placed in the body stays a compact download.",
+    description: "Add one point people and agents will read to understand a Thread and decide what's next — make it additive: stamp for one-line agreement or disagreement, respond or mark_as_response for requests. Prose refs stay citations; links create deliberate reply/contest edges.",
     inputSchema: {
       threadId: string2().describe("the thread id, e.g. thr_…"),
       type: _enum(CONTRIBUTION_TYPES).describe("the contribution type (AD-066 taxonomy)"),
-      body: string2().min(1).describe("the contribution text"),
+      body: string2().min(1).describe(`the contribution markdown. ${CONTRIBUTION_BODY_GUIDANCE}`),
       idempotencyKey: string2().min(1).max(200).optional().describe("stable key for this ONE logical contribution (≤200 chars), e.g. cron-run/work-item + output slot; safe retries return the original contribution. Reusing it with different content is a conflict."),
-      summary: string2().max(500).optional().describe("optional gist, 1-2 short sentences — HARD LIMIT 500 characters (the request is rejected past it, so keep well under). Becomes the recall snippet AND sharpens recall for long contributions (it's prepended to the embedded text); write one when the body is long"),
+      summary: string2().max(500).optional().describe(`optional gist: ${CONTRIBUTION_SUMMARY_GUIDANCE}. It is what newcomers read first (the Thread distillate and the recall snippet) and it sharpens recall for long bodies; write one when the body is long`),
       confidence: number2().int().min(0).max(100).optional().describe("optional 0–100 confidence"),
       computerSessionId: string2().optional().describe("the attached computer session that produced this result, cms_…"),
-      attachmentIds: array(string2()).max(10).optional().describe("Thread-scoped files to preserve with the contribution. To show computer_verify image evidence inline, also place its returned attachments[].markdown in the body."),
+      attachmentIds: array(string2()).max(10).optional().describe("Thread-scoped files to preserve with the contribution. To show Computer media inline, place the attachments[].markdown returned by computer_verify or computer_export in the body; an attachment not placed in the body stays a compact download."),
       mentions: array(object({
         kind: _enum(["person", "contribution", "artifact"]),
         id: string2(),
@@ -11228,8 +11232,8 @@ var ACTION_DEFINITIONS = [
     description: "Edit the body or summary of your own contribution while preserving audit history; type and deliberate links stay fixed, and body refs update with the edited prose. Use this to sharpen the same point; post a new contribution for a genuinely different point.",
     inputSchema: {
       contributionId: string2().describe("your contribution's id, con_…"),
-      body: string2().min(1).describe("the replacement markdown body"),
-      summary: string2().max(500).optional().describe("optional gist, 1-2 short sentences (HARD LIMIT 500 characters) — omit to leave unchanged, empty string to clear")
+      body: string2().min(1).describe(`the replacement markdown body. ${CONTRIBUTION_BODY_GUIDANCE}`),
+      summary: string2().max(500).optional().describe(`optional gist: ${CONTRIBUTION_SUMMARY_GUIDANCE} — omit to leave unchanged, empty string to clear`)
     },
     surfaces: ["mcp", "cli"],
     toolset: "loop",
@@ -11351,7 +11355,7 @@ var ACTION_DEFINITIONS = [
       spaceId: string2().describe("the space, spc_…"),
       topicId: string2().describe("the topic to file it under, top_…"),
       title: string2().min(1).describe("name the question, outcome, investigation, instance, or standing concern — not a status"),
-      objective: string2().min(1).describe("what this Thread should accomplish; for finite work, state what done means")
+      objective: string2().min(1).describe("what this Thread should accomplish, in plain words a newcomer understands; for finite work, state what done means")
     },
     surfaces: ["mcp", "cli"],
     toolset: "loop",
@@ -12103,8 +12107,8 @@ var ACTION_DEFINITIONS = [
     inputSchema: {
       requestId: string2().describe("the request id, req_…"),
       type: _enum(CONTRIBUTION_TYPES).describe("the contribution type"),
-      body: string2().min(1).describe("your response"),
-      summary: string2().max(500).optional().describe("optional gist, 1-2 short sentences (HARD LIMIT 500 characters)"),
+      body: string2().min(1).describe(`your response markdown. ${CONTRIBUTION_BODY_GUIDANCE}`),
+      summary: string2().max(500).optional().describe(`optional gist: ${CONTRIBUTION_SUMMARY_GUIDANCE}`),
       confidence: number2().int().min(0).max(100).optional(),
       computerSessionId: string2().optional().describe("computer receipt to cite when the response came from computer work, cms_…"),
       attachmentIds: array(string2()).max(10).optional().describe("Thread-scoped files preserved with the response; place computer_verify attachments[].markdown in the body for exact inline image placement")

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lambdacurry/arbor",
-  "version": "0.23.17",
+  "version": "0.23.19",
   "description": "The Arbor CLI — a shared workspace for people and agents. The human + headless-agent write path over Arbor's guarded operation surface.",
   "keywords": [
     "agents",