@rmrdeveloper/sideroom-pi 9.0.0 → 9.1.0

package/extensions/visual-context/pairing.ts

@@ -84,8 +84,7 @@ export async function ensurePairing(
     flag: 'wx',
   });
   try {
-    // Linking a complete file prevents concurrent Pi processes from reading
-    // a half-written credential or replacing another process's identity.
+
     linkSync(staging, join(directory, FILE));
   } catch (cause) {
     if (!hasCode(cause, 'EEXIST')) {

package/extensions/visual-context/parse-astro.ts

@@ -40,8 +40,6 @@ function byteOffsets(source: string): Int32Array {
   return offsets;
 }
 
-// Astro's self-closing node end may precede its attributes. Find only the end
-// of its original opening tag, respecting quoted and braced attribute values.
 function openingTagEnd(source: string, start: number): number {
   let quote = '';
   let braces = 0;
@@ -87,16 +85,16 @@ export function parseAstro(source: string): ParsedMarkup {
           : undefined;
       const value =
         expression === undefined ? undefined : literalText(expression);
-      // Expression text is JS source, not rendered text. Visit only real tags.
+
       return value === undefined
         ? [
-            {
-              kind: 'dynamic',
-              children: node.children
-                .filter((child) => child.type !== 'text')
-                .flatMap(convert),
-            },
-          ]
+          {
+            kind: 'dynamic',
+            children: node.children
+              .filter((child) => child.type !== 'text')
+              .flatMap(convert),
+          },
+        ]
         : [{ kind: 'text', value }];
     }
     if (node.type === 'root' || node.type === 'fragment') {
@@ -117,8 +115,7 @@ export function parseAstro(source: string): ParsedMarkup {
     const closingTag = reportedRange
       .slice(reportedRange.lastIndexOf('</'))
       .replace(/\s+>$/u, '>');
-    // When the compiler's closing position is wrong, the verified opening tag
-    // is still a valid source range; never extend it to a guessed closing tag.
+
     const end =
       isClosed || closingTag !== `</${node.name}>` ? openingEnd : reportedEnd;
     if (!node.position?.end && !isClosed) {

package/extensions/visual-context/parse-jsx.ts

@@ -50,7 +50,7 @@ export function parseJsx(source: string, typescript: boolean): ParsedMarkup {
     let attributes: Record<string, string | undefined> = {};
     for (const attribute of node.openingElement.attributes) {
       if (attribute.type === 'JSXSpreadAttribute') {
-        // A spread may overwrite descriptors or make captured text private.
+
         attributes = { hidden: undefined, contenteditable: undefined };
         continue;
       }
@@ -92,7 +92,7 @@ export function parseJsx(source: string, typescript: boolean): ParsedMarkup {
     }
     const children = node.children.flatMap((child): readonly SourceNode[] => {
       if (child.type === 'JSXText') {
-        // JSX trims indentation at line boundaries, unlike HTML textContent.
+
         const lines = child.value.replace(/\t/gu, ' ').split(/\r\n|\n|\r/u);
         const text = lines
           .map((line, index) => {

package/extensions/visual-context/parse-vue.ts

@@ -96,7 +96,7 @@ export function parseVue(source: string): ParsedMarkup {
         prop.arg.type !== NodeTypes.SIMPLE_EXPRESSION ||
         !prop.arg.isStatic
       ) {
-        // An unknown key or object binding may replace a static id.
+
         attributes.id = undefined;
         attributes.hidden = undefined;
         attributes.contenteditable = undefined;

package/extensions/visual-context/setup.ts

@@ -63,15 +63,15 @@ export function prepareSetup(cwd: string, project: string) {
       args:
         inspected.manager === 'npm'
           ? [
-              'install',
-              '--save-dev',
-              `${compilerPackage(inspected.kind)}@${INSPECTOR_VERSION}`,
-            ]
+            'install',
+            '--save-dev',
+            `${compilerPackage(inspected.kind)}@${INSPECTOR_VERSION}`,
+          ]
           : [
-              'add',
-              '--dev',
-              `${compilerPackage(inspected.kind)}@${INSPECTOR_VERSION}`,
-            ],
+            'add',
+            '--dev',
+            `${compilerPackage(inspected.kind)}@${INSPECTOR_VERSION}`,
+          ],
     },
     checkScripts: Object.keys(manifest.scripts ?? {}).filter((script) =>
       ['check', 'typecheck', 'lint', 'test', 'build'].includes(script),

package/extensions/visual-context/source.ts

@@ -240,7 +240,6 @@ export function candidateIsCurrent(
   return currentCandidates(cwd, [candidate]).length === 1;
 }
 
-// Each call owns its file versions; no validation survives into another prompt.
 export function currentCandidates(
   cwd: string,
   candidates: readonly SourceCandidate[],
@@ -290,8 +289,6 @@ export function currentCandidates(
   });
 }
 
-// A path that turned into a file on the way reports ENOTDIR, which means the
-// remembered source is gone rather than unreadable.
 function isGone(cause: unknown): boolean {
   return (
     isMissingFile(cause) ||

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@rmrdeveloper/sideroom-pi",
-  "version": "9.0.0",
-  "description": "Pi coding-agent package that asks clarifying questions, shows a live todo board, enforces coding guidelines, and will not call it done while your checks are red.",
+  "version": "9.1.0",
+  "description": "Make \"done\" mean done for Pi. Asks before it guesses, enforces your coding rules, and refuses to finish while your project's checks are red.",
   "type": "module",
   "files": [
     "extensions",
@@ -17,15 +17,15 @@
     "commitlint": "commitlint",
     "types": "tsc --noEmit",
     "test": "node --test 'extensions/**/*.test.ts' 'scripts/**/*.test.mjs'",
-    "lint": "biome lint extensions assets/visual-context/browser scripts commitlint.config.mjs",
-    "lint:fix": "biome lint --write extensions assets/visual-context/browser scripts commitlint.config.mjs",
-    "format": "biome format --write extensions assets/visual-context/browser scripts package.json biome.json commitlint.config.mjs .changeset/config.json",
-    "format:check": "biome format extensions assets/visual-context/browser scripts package.json biome.json commitlint.config.mjs .changeset/config.json",
+    "lint": "eslint extensions assets/visual-context/browser scripts commitlint.config.mjs eslint.config.mjs package.json tsconfig.json .changeset/config.json",
+    "lint:fix": "eslint extensions assets/visual-context/browser scripts commitlint.config.mjs eslint.config.mjs package.json tsconfig.json .changeset/config.json --fix",
+    "format": "eslint extensions assets/visual-context/browser scripts commitlint.config.mjs eslint.config.mjs package.json tsconfig.json .changeset/config.json --fix",
+    "format:check": "eslint extensions assets/visual-context/browser scripts commitlint.config.mjs eslint.config.mjs package.json tsconfig.json .changeset/config.json",
     "preview": "node scripts/render-preview.mjs",
     "cache:report": "node scripts/cache-report.mjs",
     "package:browser": "node scripts/package-browser.mjs",
     "check:if-blocks": "node scripts/check-if-blocks.mjs",
-    "check": "npm run types && npm run check:if-blocks && biome check extensions assets/visual-context/browser scripts package.json biome.json commitlint.config.mjs .changeset/config.json && npm test"
+    "check": "npm run types && npm run check:if-blocks && npm run lint && npm test"
   },
   "engines": {
     "node": ">=22.19.0"
@@ -86,17 +86,23 @@
     "typebox": "*"
   },
   "devDependencies": {
-    "@biomejs/biome": "2.5.11",
     "@changesets/cli": "^3.0.2",
     "@commitlint/cli": "^21.2.2",
     "@commitlint/config-conventional": "^21.2.2",
     "@earendil-works/pi-coding-agent": "1.2.0",
     "@earendil-works/pi-tui": "1.2.0",
+    "@eslint/js": "^10.0.1",
+    "@stylistic/eslint-plugin": "^5.10.0",
     "@types/node": "^22.20.1",
     "@types/ws": "^8.18.2",
+    "eslint": "^10.13.0",
+    "eslint-plugin-jsonc": "^3.4.2",
+    "eslint-plugin-no-comments": "^1.2.1",
     "fflate": "0.8.3",
+    "globals": "^17.13.0",
     "typebox": "1.3.7",
-    "typescript": "^5.6.0"
+    "typescript": "^5.6.0",
+    "typescript-eslint": "^8.72.0"
   },
   "dependencies": {
     "@astrojs/compiler": "^4.0.0",

package/skills/sideroom-guidelines/SKILL.md

@@ -11,7 +11,7 @@ metadata:
 
 ## Activation Contract
 
-Before `write` or `edit`, call `sideroom_guidelines` with the target file's `path`. It returns this whole skill and the matching complete language guide, or only this skill for unsupported languages. Reuse loaded guides during the same agent run; load any additional target language before editing it. Reload after compaction or a new run.
+Before `write` or `edit`, call `sideroom_guidelines` with the target file's `path`. On first load it returns this whole skill and the matching complete language guide, or only this skill for unsupported languages. Later calls return only missing complete documents; an already loaded target receives a short acknowledgement. Reuse loaded guides during the same agent run; load any additional target language before editing it. Reload after compaction or a new run.
 
 Alternatively, load this whole skill with `read`, without `offset` or `limit`, using the absolute packaged path shown in Available Skills. For each supported target language, also fully load its exact guide from `references/languages/`. Both routes satisfy the same gate only on successful, complete delivery.
 

package/skills/sideroom-persona/SKILL.md

@@ -89,12 +89,14 @@ dead-locked.
 
 ### What steering means
 
-The extension sends a corrective steer after a degraded artifact block or a
-prohibited assistant message. Both moments happen while the agent is working, so
-the steer travels through `pi.sendMessage` with `{ triggerTurn: true, deliverAs:
-'steer' }` and joins the current run. A steer sent after the run ended belongs
-to the guidelines review and the walkthrough offer, which append a
-`custom_message` entry on `agent_before_settle` instead.
+The extension retains a correction for the latest successful final response.
+A later clean response, tool-use response, error, or cancellation clears it.
+Corrections append a `custom_message` entry on a completed, quiet
+`agent_before_settle`: they join an existing review/check continuation when
+possible, and request a continuation only if the final response still needs
+correction. Aborts and queued work postpone corrections without consuming them.
+Degraded artifact warnings use `{ triggerTurn: false, deliverAs: 'steer' }`
+and wait for the next natural response.
 At most three steers are sent per agent run.
 
 ## Boundaries

package/skills/sideroom-user-stories/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: sideroom-user-stories
+description: "Write, revise, review, or split user stories and their acceptance criteria from a brief or existing ticket. Use for functional stories and technical enablement tickets, independent of the issue tracker. Use sideroom-grill for an open feature plan; this skill owns the resulting story, not implementation or ticket publication."
+license: MIT
+metadata:
+  author: RMRdeveloper
+  version: "1.0"
+---
+
+# Sideroom user stories
+
+## Scope and authority
+
+Produce stories that product, development, and QA can interpret alike without
+reconstructing the conversation. Write in the user's language, preserving the
+project's domain terms.
+
+Writing or reviewing a story authorizes text in the conversation only. Save a
+file, publish or edit a remote ticket, set metadata, or change workflow state
+only when the user requests that action. Story work does not authorize
+implementation, glossary edits, or architectural decisions.
+
+## Workflow
+
+1. **Read the available facts.** Start with the brief or existing ticket and
+   the relevant project conventions, glossary, approved specs, and linked
+   dependencies. Inspect code only for facts needed to distinguish current
+   behavior from the requested change; code does not establish product intent.
+   Reuse local ticket conventions, including required fields, without
+   importing another project's roles, boards, labels, estimates, or priorities.
+   If the tracker is available, search the relevant project for duplicates
+   before proposing a new ticket. Otherwise state that duplicates were not
+   checked; do not claim uniqueness or invent issue keys.
+2. **Identify the need.** State the actor receiving value, the capability,
+   the useful result, and the boundaries. Prefer a complete user outcome over
+   separate UI, API, and persistence stories. Split independently valuable
+   outcomes; use technical tasks for coordination or honor an explicitly
+   approved project split. Each proposed story must retain a clear result and
+   explain any real dependency.
+3. **Resolve material gaps.** Ask through `sideroom_ask` only about missing
+   facts or decisions that change scope or acceptance. Load
+   `../sideroom-grill/SKILL.md` when the broader feature plan is open, or
+   `../sideroom-architecture/SKILL.md` for an unresolved architectural choice.
+   Reuse settled answers rather than repeating an interview. If clarification
+   is unavailable or the user wants a draft, mark it as a draft and list open
+   questions separately. Never turn a proposed permission, rule, metric,
+   dependency, or error response into an agreed requirement.
+4. **Draft the story.** Read [templates](references/templates.md) before
+   drafting or rewriting. The normal output is a result-oriented title, a
+   story sentence, scope, and acceptance criteria. Add other sections only
+   when they clarify a real condition. A technical enablement story names
+   its consumer and the capability it enables. For a bug, use the bug format
+   instead of forcing a story sentence.
+5. **Review the result.** Read [review guidance](references/review.md) before
+   returning a draft or review. Trace each criterion to scope or a business
+   rule; remove accidental new work and repeated content. Check the successful
+   path and only the failure or boundary cases that can change the result.
+   A story is ready for review when each criterion has an objective pass/fail
+   result and no unresolved question changes the promised behavior. If that
+   gate fails, return the draft with its blockers, not a readiness claim.
+
+## Output boundaries
+
+For a review, report concrete ambiguities, missing outcomes, or unsupported
+requirements; propose corrected wording without silently expanding scope.
+For a split, show each story and explain the actual dependency between them.
+
+Keep the ticket focused on need, behavior, rules, and observable results.
+Implementation steps, source paths, logs, and routine lint/build commands
+belong in implementation records. Link approved design decisions when needed;
+include their relevant behavioral consequences in the ticket itself. Technical
+contracts belong in acceptance only when they define the agreed deliverable.
+
+When publication is requested, confirm the destination and required metadata
+from project facts or the user, check duplicates, and explain blocking links
+in the correct direction: the prerequisite blocks the dependent. Report what
+was actually saved; if access or required facts are missing, return the draft
+and the missing information instead of claiming publication.

package/skills/sideroom-user-stories/references/review.md

@@ -0,0 +1,84 @@
+# Story review
+
+Apply this review to each story, including stories proposed in a split.
+Report findings against specific wording, with a correction or a question
+that would resolve the issue.
+
+## Title, actor, and value
+
+- The title names a recognizable result and business object.
+- The actor receives the value; an implementation team is not a substitute.
+- The capability uses a precise action such as consult, assign, cancel, or
+  configure. Replace “improve” or “manage” with what actually changes.
+- The value explains why the actor needs the capability without promising
+  metrics or benefits unsupported by the agreed scope.
+- One main need has clear boundaries. Split independent outcomes rather
+  than mechanically separating implementation layers.
+
+## Scope and rules
+
+Scope states what can be done or seen and which state changes. Business
+rules state the conditions governing that behavior: permissions, restrictions,
+precedence, ownership, or a source of truth when relevant.
+
+A rule should survive a different implementation. “A reservation has at most
+one active holder” is a rule; a proposed database index is a design choice
+unless that index is itself the technical deliverable.
+
+Include agreed behavior, not guesses. An unresolved permission or conflict
+policy is a question, not a criterion. Link decisions with enough behavioral
+detail that QA can understand the expected outcome without reading the code.
+
+## Acceptance criteria
+
+Each criterion needs a relevant precondition, an action or event, and an
+observable result. Use Given/When/Then for conditional behavior; a direct
+bullet is sufficient when it still carries all three parts.
+
+Each criterion must be:
+
+- Observable through a public interface or a business result.
+- Specific enough that two reviewers agree whether it passes.
+- Focused on one main rule rather than a chain of unrelated behaviors.
+- Traceable to scope or an agreed business rule, without introducing new work.
+- Neutral to implementation, except for an agreed technical contract.
+
+Cover the successful path. Add only cases that can change the outcome:
+authorization and visibility, invalid input and recovery, empty data,
+persistence on a later consultation, retries and duplicate requests,
+concurrent changes, dates and limits, dependency failure, or agreed legacy
+compatibility. Ask about unknown behavior instead of completing this list
+by assumption. Measurable performance requirements need an agreed threshold
+and conditions; never invent them.
+
+| Weak wording | Correction |
+| --- | --- |
+| “Works correctly” | Name the initial state, event, and final result. |
+| “The interface is intuitive” | State the action the actor can complete and the feedback received. |
+| “Handle errors” | Name the relevant failure and the observable state afterward. |
+| “According to the design” | State the rule and link the specific approved design if needed. |
+| “Create an endpoint, table, and tests” | State the observable contract or move implementation steps out. |
+| “Pass lint and update documentation” | Keep routine delivery checks in the project's Definition of Done, not functional acceptance. |
+
+Acceptance describes behavior. Tests demonstrate it; PR checks record the
+tools and commands used. Do not turn those records into user requirements.
+
+## Readiness check
+
+Before calling a story ready for review, confirm:
+
+- The actor, capability, and useful result are explicit.
+- Scope and acceptance describe the same single need.
+- Relevant business rules and outcome-changing edge cases are settled.
+- Every criterion can objectively pass or fail.
+- Optional sections clarify something real and do not repeat other sections.
+- Dependencies have real references and an explanation when known.
+- Open questions are outside the promised requirements; unresolved behavior
+  that changes acceptance keeps the story marked as a draft.
+- Technical detail defines an agreed contract or remains outside the story.
+- Tracker conventions and metadata come from the project or user.
+- Duplicate search and publication status are reported honestly.
+
+This is a semantic review, not proof of product approval, implementation,
+or QA completion. Do not mark a remote workflow state merely because this
+checklist passes.

package/skills/sideroom-user-stories/references/templates.md

@@ -0,0 +1,131 @@
+# Story templates
+
+Use the user's language for headings and content; translate these English
+examples when needed. Replace placeholders with agreed facts; omit optional
+sections that add no information. Keep unresolved questions outside the
+promised scope.
+
+## Functional story
+
+Title: `<Action verb + result and business object>`
+
+```md
+As a <person>, I want <capability>, so that <useful, verifiable result>.
+
+## Context
+
+<Why this is needed, or the contrast between current and expected behavior.>
+
+## Scope
+
+- <Included capability and its boundaries.>
+
+## Business rules
+
+- <Permission, restriction, or precedence that changes the outcome.>
+
+## Acceptance criteria
+
+- Given <initial state>, when <action or event>, then <observable result>.
+
+## Dependencies
+
+- <Actual reference> — <required capability and reason it blocks this work>.
+
+## Out of scope
+
+- <Nearby work that could be mistaken for part of this delivery>.
+```
+
+The story sentence, scope, and acceptance criteria are required. Context,
+business rules, dependencies, and exclusions are conditional. A project may
+require additional fields; use its conventions rather than inventing values.
+
+Choose the most specific role whose workflow improves. Put secondary
+beneficiaries in scope only when relevant. The capability describes what the
+actor achieves, not a screen, table, or endpoint. The value explains a useful
+consequence, not “so that I can use the feature” or an unsubstantiated benefit.
+
+A title must distinguish the result in a list without opening the ticket.
+Keep product vocabulary; include technology only when it defines the
+deliverable. Prefer “View orders by delivery status” over
+“Changes to Orders.vue”.
+
+## Technical enablement
+
+Use a developer or another technical consumer only when they receive the
+value. Keep the functional template, but make the enabled capability explicit:
+
+> As an integration developer, I want to query an order's status through a
+> stable contract, so that I can report its progress without duplicating
+> tracking rules.
+
+Include agreed schemas, routes, constraints, or compatibility rules when those
+are the deliverable. “Create a table, endpoint, and tests” is implementation
+work, not an observable acceptance criterion. If the contract is undecided,
+resolve it or return a draft; do not invent its fields.
+
+## Bug
+
+```md
+## Observed behavior
+
+<What happens and who is affected.>
+
+## Expected behavior
+
+<Correct result supported by a rule or decision.>
+
+## Steps to reproduce
+
+1. <Known initial state.>
+2. <Action.>
+3. <Observed result.>
+
+## Impact
+
+<Known affected users, frequency, and blockers; state what needs confirmation.>
+
+## Acceptance criteria
+
+- Given <condition that reproduces the defect>, when <action>,
+  then <correct observable result>.
+```
+
+Use minimal anonymized reproduction data. Keep secrets and unnecessary
+personal information out. If reproduction is unknown, state that explicitly
+rather than supplying fictional steps.
+
+## Complete functional example
+
+The permissions and behavior here are illustrative, not defaults for a project.
+
+**Title:** Allow cancellation of a pending reservation
+
+As a reservation holder, I want to cancel my reservation before confirmation,
+so that I can release the time slot I no longer need.
+
+### Scope
+
+- The holder can cancel their own reservation while it is pending.
+- The holder can view the resulting status when reopening the reservation.
+
+### Business rules
+
+- Only the reservation holder can cancel the reservation.
+- This flow does not allow cancellation of a confirmed reservation.
+
+### Acceptance criteria
+
+- Given a pending reservation, when its holder cancels it, then the reservation
+  becomes cancelled.
+- Given a cancelled reservation, when its holder views it again, then they see
+  the cancelled status.
+- Given another person's reservation, when someone attempts to cancel it,
+  then the action is denied and the reservation retains its status.
+- Given a confirmed reservation, when its holder attempts to cancel it through
+  this flow, then cancellation is rejected and the reservation stays confirmed.
+
+### Out of scope
+
+- Cancelling confirmed reservations or processing refunds.