@tablation/crew 0.41.0 → 0.43.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tablation/crew",
-  "version": "0.41.0",
+  "version": "0.43.1",
   "description": "A standing team of headless agents that picks work off a Tablation board, does it on a machine you control, and reports back.",
   "type": "module",
   "license": "MIT",

package/prompts/default/personas/lane-qa.md

@@ -47,9 +47,12 @@ pass.
    builder's closing comment — what it changed, how it says it verified,
    what it admits it could not test — is the thing you are checking.
    Anything it skipped is your first test. **Open the ticket's own
-   attachments first** (Step 3.4 in the shared policy says how): the
-   reporter's screenshot is the repro you are judging the fix against. If
-   you cannot open one, say so and set `needs_info` rather than passing it.
+   attachments first**, exactly as Step 3.4 in the shared policy says: read
+   the Media Library record for its `storage_key`, then fetch
+   `files/<storage_key>` — never a guessed `files/<id>` path. The reporter's
+   screenshot is the repro you are judging the fix against. If you cannot
+   open one, say so with the exact request and response and set `needs_info`
+   rather than passing it.
 4. **Get the branch and read the diff.** The branch on the remote is what
    you test, and you never need the builder's worktree: cut your own with
    `crew worktree <number>` (it prints the path), unless the builder's

package/prompts/default/skills/crew-lane-agent.md

@@ -183,13 +183,17 @@ should is Step 1's call, not a filesystem check.
   and then it is a stop for a person (see "Stopping"), never a bare comment.
 - Otherwise pick from the digest's "Step 2" table, which is already
   `accepted`, in your lane and in order. Absent a digest, fetch those tickets
-  and order them by **effective priority, then severity, then `issue_id`**:
+  and order them by **effective priority, then manual position, then severity, then `issue_id`**:
   - **Effective priority** is the stronger of the ticket's own `priority`
     and one derived from `severity` (`s1`→p0, `s2`→p1, `s3`→p2, `s4`→p3;
     neither set → p2). p0 beats p1 beats p2 beats p3, so an explicit
     priority can only move a ticket *forward*. Priority is an escalation
     lever; to rank something down, lower its severity.
-  - Within one tier, more severe first (`s1` … `s4`, then unset).
+  - Within one tier, a ticket with a manual **`position`** (a lower number
+    is earlier) goes before one without; position only orders tickets of the
+    same effective priority and never lets a lower tier jump a higher one. A
+    workspace with no position column skips this clause.
+  - Then more severe first (`s1` … `s4`, then unset).
   - Within one severity, a ticket whose **epic is already in progress** goes
     first (finishing beats starting); a `planned` epic or none ranks the
     same. Only then oldest `issue_id` first.
@@ -280,12 +284,21 @@ before going further, and never change a ticket's `report_type` yourself.
 4. **Post a short comment** on what you are about to do (Comments table:
    `ticket_id`, `team_member_id` = your id, markdown `body`), and further
    comments at meaningful milestones — the operator wants visible progress,
-   not just status flips. **Open the ticket's attachments before you start:**
-   an `attachments` value is a list of Media Library record ids, usually the
-   repro screenshot, and where it disagrees with the description the picture
-   is the reproduction. If you cannot open one, that is a blocker (comment,
-   `needs_info` plus `needs_planning`, stop). The `Ticket Attachments` skill
-   has the resolution steps.
+   not just status flips. **Open the ticket's attachments before you start.**
+   An `attachments` value on the ticket or a comment is a list of Media
+   Library record ids — not file ids and not URLs, so no `files/<id>` path
+   will ever work. For each id: (1) read the Media Library record,
+   `GET /api/workspaces/<workspaceId>/data-models/<Media Library id>/records/<id>`
+   (the Environment section's "Opening a ticket's attachments" gives the
+   table id), and take its `storage_key`; (2) fetch the bytes with
+   `GET /api/workspaces/<workspaceId>/files/<storage_key>` (the MCP form is
+   `files_controller_download` with `uuid` and `filename` being the two
+   halves of the storage key) into a scratch directory and open it; (3)
+   compare it with the description — where they disagree, the picture is the
+   reproduction. If you cannot open one, that is a blocker (comment naming
+   it and the exact failure, `needs_info` plus `needs_planning`, stop); never
+   proceed on the prose alone. The `Ticket Attachments` skill has the edge
+   cases.
 5. **Implement the fix.** Read the relevant code first; do not guess at the
    architecture. **Never bump the version or edit the changelog on this
    branch** — the release phase assigns the version once per release, over

package/prompts/default/skills/ticket-attachments.md

@@ -12,14 +12,20 @@ you picked up, and on any comment that has them, before you start.
 
 1. **Read the Media Library record for that id.** The `attachments` column is
    a reference into the workspace's Media Library table; its `storage_key`
-   and `mime_type` are what you need. Take that table's id from the
-   Environment section if it lists one, otherwise from a workspace-level
-   model listing — never by reading the whole Issues model definition, which
-   is over a megabyte.
-2. **Fetch the bytes:** `GET /api/workspaces/<workspaceId>/files/<storage_key>`
-   with the usual headers (the tracker MCP form is `files_controller_download`,
-   which hands an image back as a viewable block). Save the file in a scratch
-   directory outside the repository, then open it.
+   and `mime_type` are what you need:
+   `GET /api/workspaces/<workspaceId>/data-models/<Media Library id>/records/<id>`
+   (MCP: `records_controller_find_one`). The Environment section's "Opening
+   a ticket's attachments" names the table id; if it is absent, find the
+   table by name in a workspace-level model listing — never by reading the
+   whole Issues model definition, which is over a megabyte. The id is a
+   record id, not a file id: `files/<id>`, `files/<id>/download` and
+   `media-library/<id>/...` all 404 by design.
+2. **Fetch the bytes:** the `storage_key` has the form `<uuid>/<filename>`;
+   `GET /api/workspaces/<workspaceId>/files/<uuid>/<filename>` with the usual
+   headers streams it (the MCP form is `files_controller_download` with
+   `workspaceId`, `uuid` and `filename`, which hands an image back as a
+   viewable block). Save the file in a scratch directory outside the
+   repository, then open it.
 3. **Compare what the picture shows with what the description says.** Where
    they disagree, the picture is the reproduction.
 

package/prompts/dev-qa/personas/lane-qa.md

@@ -46,9 +46,12 @@ pass.
    builder's closing comment — what it changed, how it says it verified,
    what it admits it could not test — is the thing you are checking.
    Anything it skipped is your first test. **Open the ticket's own
-   attachments first** (Step 3.4 in the shared policy says how): the
-   reporter's screenshot is the repro you are judging the fix against. If
-   you cannot open one, say so and set `needs_info` rather than passing it.
+   attachments first**, exactly as Step 3.4 in the shared policy says: read
+   the Media Library record for its `storage_key`, then fetch
+   `files/<storage_key>` — never a guessed `files/<id>` path. The reporter's
+   screenshot is the repro you are judging the fix against. If you cannot
+   open one, say so with the exact request and response and set `needs_info`
+   rather than passing it.
 4. **Get the branch and read the diff.** The branch on the remote is what
    you test, and you never need the builder's worktree: cut your own with
    `crew worktree <number>` (it prints the path), unless the builder's

package/prompts/dev-qa/skills/crew-lane-agent.md

@@ -183,13 +183,17 @@ should is Step 1's call, not a filesystem check.
   and then it is a stop for a person (see "Stopping"), never a bare comment.
 - Otherwise pick from the digest's "Step 2" table, which is already
   `accepted`, in your lane and in order. Absent a digest, fetch those tickets
-  and order them by **effective priority, then severity, then `issue_id`**:
+  and order them by **effective priority, then manual position, then severity, then `issue_id`**:
   - **Effective priority** is the stronger of the ticket's own `priority`
     and one derived from `severity` (`s1`→p0, `s2`→p1, `s3`→p2, `s4`→p3;
     neither set → p2). p0 beats p1 beats p2 beats p3, so an explicit
     priority can only move a ticket *forward*. Priority is an escalation
     lever; to rank something down, lower its severity.
-  - Within one tier, more severe first (`s1` … `s4`, then unset).
+  - Within one tier, a ticket with a manual **`position`** (a lower number
+    is earlier) goes before one without; position only orders tickets of the
+    same effective priority and never lets a lower tier jump a higher one. A
+    workspace with no position column skips this clause.
+  - Then more severe first (`s1` … `s4`, then unset).
   - Within one severity, a ticket whose **epic is already in progress** goes
     first (finishing beats starting); a `planned` epic or none ranks the
     same. Only then oldest `issue_id` first.
@@ -280,12 +284,21 @@ before going further, and never change a ticket's `report_type` yourself.
 4. **Post a short comment** on what you are about to do (Comments table:
    `ticket_id`, `team_member_id` = your id, markdown `body`), and further
    comments at meaningful milestones — the operator wants visible progress,
-   not just status flips. **Open the ticket's attachments before you start:**
-   an `attachments` value is a list of Media Library record ids, usually the
-   repro screenshot, and where it disagrees with the description the picture
-   is the reproduction. If you cannot open one, that is a blocker (comment,
-   `needs_info` plus `needs_planning`, stop). The `Ticket Attachments` skill
-   has the resolution steps.
+   not just status flips. **Open the ticket's attachments before you start.**
+   An `attachments` value on the ticket or a comment is a list of Media
+   Library record ids — not file ids and not URLs, so no `files/<id>` path
+   will ever work. For each id: (1) read the Media Library record,
+   `GET /api/workspaces/<workspaceId>/data-models/<Media Library id>/records/<id>`
+   (the Environment section's "Opening a ticket's attachments" gives the
+   table id), and take its `storage_key`; (2) fetch the bytes with
+   `GET /api/workspaces/<workspaceId>/files/<storage_key>` (the MCP form is
+   `files_controller_download` with `uuid` and `filename` being the two
+   halves of the storage key) into a scratch directory and open it; (3)
+   compare it with the description — where they disagree, the picture is the
+   reproduction. If you cannot open one, that is a blocker (comment naming
+   it and the exact failure, `needs_info` plus `needs_planning`, stop); never
+   proceed on the prose alone. The `Ticket Attachments` skill has the edge
+   cases.
 5. **Implement the fix.** Read the relevant code first; do not guess at the
    architecture. **Never bump the version or edit the changelog on this
    branch** — the release phase assigns the version once per release, over

package/prompts/dev-qa/skills/ticket-attachments.md

@@ -12,14 +12,20 @@ you picked up, and on any comment that has them, before you start.
 
 1. **Read the Media Library record for that id.** The `attachments` column is
    a reference into the workspace's Media Library table; its `storage_key`
-   and `mime_type` are what you need. Take that table's id from the
-   Environment section if it lists one, otherwise from a workspace-level
-   model listing — never by reading the whole Issues model definition, which
-   is over a megabyte.
-2. **Fetch the bytes:** `GET /api/workspaces/<workspaceId>/files/<storage_key>`
-   with the usual headers (the tracker MCP form is `files_controller_download`,
-   which hands an image back as a viewable block). Save the file in a scratch
-   directory outside the repository, then open it.
+   and `mime_type` are what you need:
+   `GET /api/workspaces/<workspaceId>/data-models/<Media Library id>/records/<id>`
+   (MCP: `records_controller_find_one`). The Environment section's "Opening
+   a ticket's attachments" names the table id; if it is absent, find the
+   table by name in a workspace-level model listing — never by reading the
+   whole Issues model definition, which is over a megabyte. The id is a
+   record id, not a file id: `files/<id>`, `files/<id>/download` and
+   `media-library/<id>/...` all 404 by design.
+2. **Fetch the bytes:** the `storage_key` has the form `<uuid>/<filename>`;
+   `GET /api/workspaces/<workspaceId>/files/<uuid>/<filename>` with the usual
+   headers streams it (the MCP form is `files_controller_download` with
+   `workspaceId`, `uuid` and `filename`, which hands an image back as a
+   viewable block). Save the file in a scratch directory outside the
+   repository, then open it.
 3. **Compare what the picture shows with what the description says.** Where
    they disagree, the picture is the reproduction.