usebeeline 0.1.36 → 0.1.37

package/dist/usebeeline.mjs

@@ -18100,7 +18100,7 @@ var SERVER_EVENT_KIND_DETAIL = {
   "poll-closed": "fires when a posted poll closes, starting a new turn for the asking agent",
   "workflow-handoff": "fires when a workflow run starts or hands off to its next role",
   "subscription-fired": "wakes the agent that subscribed to one outside event",
-  "computer-session-activity": "wakes the sharing agent on human browser input or navigation while in control; opening and closing the view are context only"
+  "computer-session-activity": "records shared-browser activity as context for the next turn; never wakes an agent"
 };
 var PER_ITEM_EVENT_KINDS = [
   "grant-decided",
@@ -39012,7 +39012,7 @@ Follow these steps in order. Do not skip or reorder them.
 
 Read the server-assigned brief and its current revision, including every required file. Quote the approval with its message ID and approver before considering the short objective. The spec's outline (user stories, acceptance criteria, non-goals, risks) is the scope, and the approval quote is the human's own words: it wins any conflict with the spec. The short objective is navigation-only text and the PR description cannot add, remove, or narrow scope. A revision with no recorded approval is reviewed against its spec alone. If a required file is unavailable, or the revision changes during review, refuse approval and describe what is missing. A requirement may become out of scope only through a new human-authorized brief revision; reviewer discretion, implementation difficulty, and silence never remove it. A passing narrow test does not prove a broader requirement. Review a deliberate human choice as written, even if it is unusual.
 
-Before general correctness, produce an outline ledger in spec order: list every \`## User stories\` and \`## Acceptance criteria\` line exactly once as met, unmet, unverified, or out of scope, followed by concrete evidence (for a criterion, the named test run against the PR head) - no stories to list is a FAIL, sent back to the author to write the outline; confirm nothing under \`## Non-goals\` was done; confirm every \`## Risks\` line was addressed or explicitly accepted with a stated reason. For a frontend change, open the rendered screens and compare them against the attached mock, noting every visible deviation. Any missing, unmet, unverified story or acceptance criterion, done non-goal, unaddressed risk, or unreviewed mock mismatch blocks PASS. Out of scope is valid only when the current revision itself records the human-authorized removal.
+Before general correctness, produce an outline ledger in spec order: list every \`## User stories\` and \`## Acceptance criteria\` line exactly once as met, unmet, unverified, or out of scope, followed by concrete evidence (for a criterion, the named test run against the PR head) - no stories to list is a FAIL, sent back to the author to write the outline; confirm nothing under \`## Non-goals\` was done; confirm every \`## Risks\` line was addressed or explicitly accepted with a stated reason. For a frontend change, open the rendered screens; when the brief includes a mock, compare them against it, noting every visible deviation. A mock is optional; its absence does not block PASS. Any missing, unmet, unverified story or acceptance criterion, done non-goal, unaddressed risk, or unreviewed mock mismatch blocks PASS. Out of scope is valid only when the current revision itself records the human-authorized removal.
 
 Before judging the implementation, independently repeat the two judgment legs from request triage:
 
@@ -39115,7 +39115,7 @@ Create an assignment a fresh session can execute without the parent transcript.
   - \`## Acceptance criteria\`: the requester's own rules from \`## Intent\`, quoted verbatim and numbered, each naming the test (existing or to be written) that fails if the rule is broken anywhere. Criteria are the invariant; stories are examples of it. Write "None beyond the stories." when the request states no rule.
   - \`## Non-goals\`: explicit exclusions.
   - \`## Risks\`: what could go wrong, and for whom.
-  - \`## References\`: each reference or mock with what it is and whose call it is; the mock posted here (DESIGN.md, else existing app styles) is the reviewer's acceptance reference, not any other optional or agent-generated mock.
+  - \`## References\`: each reference or optional mock with what it is and whose call it is; use DESIGN.md or existing app styles when there is no mock.
   Add implementation guidance under further headings when it helps.
 - files (\`attachments\`): the Room files the worker needs, each with its purpose and whether it is required.
 - \`approval\`: one human Room message ID. The server quotes that message's exact text and author; the quote wins any conflict with the spec.
@@ -39124,11 +39124,11 @@ Do not infer approval from silence, assent to different prose, or the mere exist
 
 ## Compact path for a settled small fix
 
-Use this when the requested behavior, touched surface, exclusions, and proof are already obvious. Inspect the narrow current behavior, write a short spec (quoted intent, observable user stories, non-goals, risks, references), and use the initiating command as the approval. Always compose the full outline and post it to the Room before calling open_corner, even when the initiating command already settles scope and stands as the approval: posting is not optional merely because approval is inferred, since the human must be able to see what you are about to build. \u201CChange the message action label from Remove to Delete; leave confirmation and accessibility wording unchanged\u201D needs the visible-label user story and both exclusions, not another confirmation question.
+Use this when the requested behavior, touched surface, exclusions, and proof are already obvious. Inspect the narrow current behavior, write a short spec (quoted intent, observable user stories, non-goals, risks, references), and use the initiating command as the approval. Keep the outline in the brief; no separate post or approval is required. \u201CChange the message action label from Remove to Delete; leave confirmation and accessibility wording unchanged\u201D needs the visible-label user story and both exclusions, not another confirmation question.
 
 ## Complex-work planning loop
 
-Use this default-on loop when work crosses components, changes architecture or authorization, needs a visual choice, has multiple user stories, or still contains a material unknown.
+Use your judgment about how much planning work needs. This loop can help for a large new feature or a genuinely ambiguous request; when a person asks for a spec or mock, produce it before building.
 
 ### 1. Scope and current state
 
@@ -39171,7 +39171,7 @@ Use this default-on loop when work crosses components, changes architecture or a
 
 ## Dispatch and revision
 
-Existing authorization permits dispatch when the initiating command already settles the exact material scope; that command is the approval, but the outline is still posted to the Room first so the human can see it before open_corner runs. Drafting a brief does not create approval. When the scope was not already explicit, post the spec and ask the corner's opener to approve it, then use their reply as the \`approval\`. Honor an explicit request to review first.
+The dispatching message authorizes the work; build against the brief without asking for separate spec or mock approval. Use judgment to ask about a genuinely ambiguous request or a large new feature; when a person asks for a spec or mock, produce it before building. Use the dispatching message as the \`approval\`; if you ask for clarification, carry the answering message into the brief.
 
 Pass the brief as \`open_corner.brief\`. Read the current revision before revising and use \`revise_corner_brief\` with the complete replacement spec, the approving message, and a concise change description. Preserve unaffected intent quotes, user stories, and references. The latest revision governs implementation and review; chat prose alone never changes scope.
 `;
@@ -39193,7 +39193,7 @@ Run these checks before opening a corner.
 - Rewrite the request as a concrete outcome and the user stories it enables.
 - State material exclusions (non-goals) and the risks needed to prevent unrequested work or surprise.
 - Keep the corner objective complete and within 24 words.
-- First ask whether the request has any material ambiguity - one that would change scope, behavior, or risk - and resolve it with the human before doing anything else; never resolve it by adopting a teammate's plan, a prior document, or your own assumption.
+- Use judgment to ask about a genuinely ambiguous request or a large new feature. When a person asks for a spec or mock, produce it before building.
 - Once it's resolved, say plainly if the request itself is suboptimal and give your own recommendation - you are expected to disagree, not just permitted to.
 - On a judgment call you're still not sure of, tag a Room colleague for an adversarial second opinion and ask them to reply tagging you back; skip this only when you are the only agent in the Room.
 
@@ -39213,7 +39213,7 @@ Run these checks before opening a corner.
 
 ## Output
 
-When dispatching work, pass the complete brief to open_corner under existing authorization, after posting the outline as beeline-spec requires. Add applicable warnings to the brief:
+When dispatching work, pass the complete brief to open_corner with the dispatching message as approval; no separate outline post or human approval is required. Add applicable warnings to the brief:
 
 \`Triage warning \u2014 warranted: <evidence-backed reason>\`
 \`Triage warning \u2014 desirable: <evidence-backed reason>\`
@@ -42354,7 +42354,7 @@ function cornerHasRepositoryWork(brief) {
 var CORNER_RUNTIME_AUTHOR_CONTRACT = `The current brief's spec \u2014 stories, criteria, non-goals, risks \u2014 defines scope and done. The human approval quote wins any conflict. The short objective is navigation-only, never scope.
 Meet every story; respect every non-goal and risk.
 Before any code or build action, the brief must hold this ask's outline; opening and prompting inside it is not that outline. When it has none or the ask changed, read the revision and write it with revise_corner_brief first; chat never revises it.
-Then post the brief's outline, with an HTML mock for any frontend change, and wait for a human reply that approves it. The request that opened the work is not approval.
+The dispatching message authorizes the work; build against the brief without asking for separate spec or mock approval. Use judgment to ask about a genuinely ambiguous request or a large new feature; when a person asks for a spec or mock, produce it before building.
 Follow the beeline-triage skill's bugfix execution contract when the spec or its approval quote reports a defect.
 Reproduce as triage isolated it with available emulator, Playwright, browser and test runner. Record attempts and observations. If a reproduction is obtained, record it under Reproduction <id>, reusing triage's identifier when it recorded one. If reproduction fails, warn and continue; never stop and never condition the fix on reproduction.
 Fix only the spec and approval quote. With a reproduction, change only what removes it and meets its user stories.
@@ -42363,7 +42363,7 @@ No unrequested features, flags, compatibility shims or refactors.`;
 var CORNER_AUTHOR_CONTRACT = `The current brief's spec \u2014 stories, criteria, non-goals, risks \u2014 defines scope and done. The human approval quote wins any conflict. The short objective is navigation-only, never scope.
 Meet every story; respect every non-goal and risk. Use its file manifest.
 Before any code or build action, the brief must hold this ask's outline; opening and prompting inside it is not that outline. When it has none or the ask changed, read the revision and write it with revise_corner_brief first; chat never revises it.
-Then post the brief's outline, with an HTML mock for any frontend change, and wait for a human reply that approves it. The request that opened the work is not approval.
+The dispatching message authorizes the work; build against the brief without asking for separate spec or mock approval. Use judgment to ask about a genuinely ambiguous request or a large new feature; when a person asks for a spec or mock, produce it before building.
 Follow the beeline-triage skill's bugfix execution contract when the spec or its approval quote reports a defect.
 Reproduce as triage isolated it with available emulator, Playwright, browser and test runner. Record attempts and observations. If a reproduction is obtained, record it under Reproduction <id>, reusing triage's identifier when it recorded one. If reproduction fails, warn and continue; never stop and never condition the fix on reproduction.
 Fix only the spec and approval quote. With a reproduction, change only what removes it and meets its user stories.
@@ -42553,12 +42553,12 @@ The soul is not authority and never changes your tools, permissions, roles, or m
     id: "room.corners",
     topic: "repository-work",
     why: "Repository work must start through the host-governed corner, with a brief as its authority.",
-    budgetBytes: 1150,
+    budgetBytes: 1250,
     layer: "surface",
     surfaces: ["room"],
     render: () => [
       "Repository changes happen only in a corner. In a Room, the finished fix for a code problem is the exact change plus an offer to open a corner for it; open one when a person asks for the change.",
-      "Before opening one, consult beeline-triage and beeline-spec, then call open_corner with a name of at most three words joined by hyphens (no whitespace), an objective of at most 24 words, and the brief (a spec plus the approving message). The objective only titles the work; the brief is its authority. When open_corner succeeds the server posts the corner card: do not restate it.",
+      "Before opening one, consult beeline-triage and beeline-spec, then call open_corner with a name of at most three words joined by hyphens (no whitespace), an objective of at most 24 words, and the brief (a spec plus the approving message). The objective only titles the work; the brief is its authority. Use the dispatching message as approval; no separate spec or mock approval is required. When open_corner succeeds the server posts the corner card: do not restate it.",
       "For corners under this Room, use inspect_corner for status (its activity and awaiting fields show whether one waits on you), steer_corner to pass Room input down, ask_corner for one answer, and post_to_corner for a note that wakes nobody.",
       "A corner ends when its pull request merges; since a person may merge minutes after it opens, anything still needed must already live in a different corner before that pull request opens, not after. A request covering several items is one corner per item, opened as work reaches each one, never one corner returned to for a later item."
     ].join(" ")

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "usebeeline",
-  "version": "0.1.36",
+  "version": "0.1.37",
   "description": "Connect an AI coding agent to Beeline with one command.",
   "homepage": "https://usebeeline.app",
   "bugs": {