syntaur 0.16.2 → 0.17.0

package/platforms/codex/skills/grab-bundle/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: grab-bundle
+description: >-
+  Claim a Syntaur todo bundle (a lightweight container grouping 2+
+  scope-mate todos under a shared plan and worktree, with no full
+  assignment overhead). Use when the user wants to start working on a
+  todo bundle: "claim bundle b:xxxx", "work on the auth-cleanup bundle",
+  or after creating one via `syntaur todo bundle new`.
+license: MIT
+metadata:
+  author: prong-horn
+  version: "1.0.0"
+---
+
+# Grab Bundle
+
+Claim a Syntaur todo bundle and set up the current workspace. The bundle
+contract is lighter than an assignment — no lifecycle transitions, no
+progress.md, no handoff/decision-record/acceptance criteria. Member todos
+keep their own `start` / `complete` lifecycle; the bundle just owns the
+shared `planDir`, `branch`, `worktreePath`, and `repository`.
+
+## Input
+
+One or two positional arguments:
+
+- A bundle id (with or without `b:` prefix) — required if multiple bundles
+  exist in the current scope.
+- Scope flags: `--workspace <slug>`, `--project <slug>`, or `--global`
+  (default).
+
+If no id is given, run `syntaur todo bundle list <scope flags>` and ask
+the user to pick.
+
+## Pre-flight check
+
+Read `.syntaur/context.json` in the current working directory.
+
+- If it already contains assignment fields (`projectSlug`/`assignmentSlug`/
+  `assignmentDir`), warn the user: "You already have an active assignment.
+  Grabbing a bundle will replace this context. Proceed?" — stop if no.
+- If it already contains different bundle fields (`bundleId` set to a
+  different id), warn: "Context is bound to bundle b:<old>. Switch to b:<new>?"
+  — stop if no.
+- If it has only `sessionId` (platform SessionStart hook seeded it), proceed
+  and merge bundle fields on top.
+
+## Step 1: Load the bundle
+
+```bash
+syntaur todo bundle show <bundle-id> <scope flags>
+```
+
+Note its scope, member todos, slug, planDir (if any), branch (if any),
+worktreePath (if any), and repository.
+
+## Step 2: Read the bundle's plan (if present)
+
+If `planDir` is set, read `<planDir>/plan.md` (and any `plan-v<N>.md` —
+prefer the highest version). This is the shared implementation plan for
+the whole bundle.
+
+## Step 3: Read each member todo
+
+For each `[t:<id>]` listed in the bundle, run
+`syntaur todo list --status open` (and `--status in_progress` and
+`--status blocked`) under the same scope, OR read the checklist markdown
+directly. Note the description, current status, and any session
+fingerprint on `in_progress` members.
+
+## Step 4: Write bundle context.json
+
+Merge bundle fields into `<workspaceRoot>/.syntaur/context.json` — never
+overwrite. Required fields:
+
+```json
+{
+  "bundleId": "<bundle.id>",
+  "bundleSlug": "<bundle.slug or null>",
+  "bundleScope": "<workspace|project|global>",
+  "bundleScopeId": "<scopeId>",
+  "todoIds": ["<id1>", "<id2>", "..."],
+  "planDir": "<planDir or null>",
+  "branch": "<branch or null>",
+  "worktreePath": "<worktreePath or null>",
+  "repository": "<repository or null>",
+  "boundAt": "<ISO 8601>"
+}
+```
+
+NO assignment fields. The `resolveAssignmentTarget` discriminator at
+`src/utils/assignment-target.ts` will throw a clean error if any assignment
+flow misfires inside a bundle worktree.
+
+If the bundle already has a worktreePath set and the user is NOT inside it,
+suggest `cd <worktreePath>` before continuing.
+
+## Step 5: Report to user
+
+Summarize:
+
+- Bundle id (b:xxxx) + slug.
+- Scope + scopeId.
+- Number of members + their descriptions + statuses.
+- Plan file path (if any).
+- Branch + worktreePath (if any).
+- Repository (if any).
+- Suggested next step:
+  - `/plan-bundle` if no plan exists yet
+  - `/bundle-worktree --branch <name>` if no worktree exists yet
+  - `/complete-bundle` if every member is done

package/platforms/codex/skills/plan-bundle/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: plan-bundle
+description: >-
+  Draft a shared implementation plan for the active Syntaur todo bundle.
+  Use when the user wants to plan a bundle, write or extend its plan.md,
+  or design an approach that covers every member todo together.
+license: MIT
+metadata:
+  author: prong-horn
+  version: "1.0.0"
+---
+
+# Plan Bundle
+
+Create or extend the bundle's shared plan file. Bundles are non-lifecycle-
+bearing containers — their "acceptance" is "every member todo is completed."
+The plan must surface this explicitly: there are no acceptance criteria of
+the bundle's own to track, only the member todos.
+
+## Step 1: Load context
+
+Read `.syntaur/context.json` from the current working directory. It must
+contain `bundleId` (a bundle context). If it instead has assignment fields,
+stop and tell the user: "Active context is an assignment, not a bundle.
+Use `/plan-assignment` instead, or `/grab-bundle <id>` to switch."
+
+Extract `bundleId`, `bundleScope`, `bundleScopeId`, `todoIds`, `planDir`.
+
+## Step 2: Read each member todo
+
+For each `t:<id>` in `todoIds`, read the description from the bundle's
+scope checklist:
+
+- workspace scope → `~/.syntaur/todos/<scopeId>.md`
+- global scope → `~/.syntaur/todos/_global.md`
+- project scope → `~/.syntaur/projects/<scopeId>/todos/<scopeId>.md`
+
+Note each member's current status. Bundled members can be `open`,
+`in_progress`, or `blocked` — a `completed` member should not be in a
+live bundle (run `syntaur doctor` if you see one).
+
+## Step 3: Create or open the plan file
+
+```bash
+syntaur todo bundle plan <bundle-id> <scope flags>
+```
+
+This prints the path to the new (or next-version) plan file. First call
+creates `plan.md`; subsequent calls create `plan-v2.md`, `plan-v3.md`, etc.
+The stub frontmatter includes `bundle:`, `todos:`, `scope:`, `status: draft`.
+A `## Members` section listing each member is pre-populated.
+
+## Step 4: Write the plan body
+
+Replace the body of the new plan file with:
+
+1. **Overview** — one paragraph: why these todos are bundled together (a
+   shared schema migration, a feature with split FE/BE work, a coordinated
+   refactor, etc.).
+2. **Tasks** — numbered list. For each task: description, files to
+   create/modify, dependencies on other tasks, complexity estimate.
+3. **Member Mapping** — for each `t:<id>` member, which numbered task(s)
+   complete it. This is the bundle equivalent of an assignment's "Acceptance
+   Criteria Mapping" — it tells the implementer "after task N is done,
+   member t:<id> can be marked completed."
+4. **Risks and Open Questions**.
+5. **Testing Strategy**.
+
+Bump `updated:` in the plan frontmatter and flip `status: draft` → `status: in_progress`.
+
+## Step 5: Mirror skills (if you also edited the skill file)
+
+If this session also added or edited any `skills/<name>/SKILL.md`, run:
+
+```bash
+npm run mirror-skills
+```
+
+This is per `AGENTS.md` — propagates to `platforms/<kind>/skills/`.
+
+## Step 6: Report to user
+
+- Plan file path (absolute).
+- Task count.
+- Open questions / risks worth flagging up front.
+- Suggested next step:
+  - `/bundle-worktree --branch <name>` to spin up the shared worktree
+  - Otherwise start implementing the first task in-place

package/skills/bundle-worktree/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: bundle-worktree
+description: >-
+  Create a git worktree for a Syntaur todo bundle and bind it to the
+  current agent session. Use when the user wants to "make a worktree for
+  this bundle", "spin up an isolated workspace for bundle b:xxxx", or set
+  up parallel work on a different bundle.
+license: MIT
+metadata:
+  author: prong-horn
+  version: "1.0.0"
+---
+
+# Bundle Worktree
+
+Atomic worktree-and-bind for a Syntaur todo bundle. Unlike the assignment
+equivalent (`/syntaur-worktree`), bundles have no lifecycle to transition
+— this skill only creates the worktree, persists the workspace on the
+bundle + every member, and writes a bundle-shaped `.syntaur/context.json`
+inside the new worktree.
+
+## When NOT to use this skill
+
+- The bundle already has a `worktreePath` set — `syntaur todo bundle show`
+  will print it; use it instead. The CLI will refuse a second worktree.
+- You want a worktree for an assignment, not a bundle — use
+  `/syntaur-worktree` instead.
+
+## Step 1: Resolve inputs
+
+Required:
+
+- `--branch <name>` — the new branch name (also the worktree dir name).
+
+Optional (with sensible defaults):
+
+- `--repository <path>` — defaults to the current working directory.
+- `--parent-branch <name>` — defaults to `main`.
+- `--worktree-path <path>` — defaults to `<repository>/.worktrees/<branch>`.
+- A bundle id positional, OR scope flags + the active context's `bundleId`.
+
+The computed worktree path is **always**
+`<repository>/.worktrees/<branch>` (never `.claude/worktrees`, never
+`~/.syntaur/worktrees`). Repo-local convention.
+
+## Step 2: Pre-flight
+
+- Confirm `.syntaur/context.json` is a bundle context (has `bundleId`,
+  no assignment fields). If it's an assignment context, stop and tell the
+  user to `/grab-bundle <id>` first.
+- Confirm `<repository>/.git` exists.
+- Confirm the branch does NOT already exist. If it does, the CLI will
+  surface a `GitWorktreeError` — surface that verbatim.
+- Confirm the bundle's existing `worktreePath` is null. The CLI rejects a
+  second worktree.
+
+## Step 3: Create worktree + bind
+
+```bash
+syntaur todo bundle worktree <bundle-id> \
+  --branch <branch> \
+  --repository <repository> \
+  --parent-branch <parent-branch> \
+  <scope flags>
+```
+
+The CLI handles the entire transactional flow via
+`createWorktreeForBundle` in `src/utils/git-worktree.ts`. On any failure
+between `git worktree add` and the persistence writes, the worktree and
+branch are removed and the error is tagged `'bundle storage'`.
+
+## Step 4: cd into the new worktree
+
+After the CLI prints `Created worktree at <path>`, `cd` into that path.
+The bundle context.json was already written inside it, so a new session
+started from that directory will read bundle fields automatically.
+
+## Step 5: Confirm context
+
+```bash
+cat .syntaur/context.json
+```
+
+The JSON should contain `bundleId`, `bundleScope`, `bundleScopeId`,
+`todoIds`, `branch`, `worktreePath`, `repository`, `boundAt` — and NO
+`assignmentDir` / `assignmentSlug` / `projectSlug`. If you see assignment
+fields, stop — something is wrong; the CLI should never emit a mixed
+context. Report the issue.
+
+## Step 6: Report to user
+
+- New worktree path.
+- Branch + parent branch.
+- Bundle id + member count.
+- Repository absolute path.
+- Reminder to `cd` into the new worktree (if the parent shell is not
+  already there).
+- Note that subsequent agent sessions opened in this directory will read
+  the bundle fields automatically.
+
+## Step 7: Mirror skills (if you also edited the skill file)
+
+If this session also touched `skills/<name>/SKILL.md`, run:
+
+```bash
+npm run mirror-skills
+```

package/skills/complete-bundle/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: complete-bundle
+description: >-
+  Bulk-complete every member todo of a Syntaur todo bundle. Use when the
+  user wants to "finish this bundle", "close out bundle b:xxxx", or mark
+  the whole bundle done after every implementation task is verified.
+license: MIT
+metadata:
+  author: prong-horn
+  version: "1.0.0"
+---
+
+# Complete Bundle
+
+Bulk-complete every open / in-progress / blocked member todo of the
+current Syntaur bundle. Bundles have no lifecycle to transition — this
+skill simply flips each member todo to `completed`, writes a log entry
+per newly-completed member, and (optionally) appends a shared summary
+to the bundle's plan.
+
+## When NOT to use this skill
+
+- The bundle has unverified work. Read each member's description and
+  confirm it is actually done in the codebase BEFORE running this skill.
+  Once a todo is `completed`, the log entry is permanent.
+- A member belongs to an assignment via `linkedAssignmentId`. The
+  assignment's own lifecycle (`/complete-assignment`) is the authoritative
+  closer; let it auto-complete the todo via the existing linked-todos
+  hook (`src/lifecycle/linked-todos.ts`).
+
+## Step 1: Load context
+
+Read `.syntaur/context.json`. It must contain `bundleId`. Extract that and
+the scope (`bundleScope` + `bundleScopeId`).
+
+## Step 2: Verify every member is done
+
+For each `t:<id>` in `todoIds`, read the description and confirm in the
+codebase that the work is complete:
+
+- Files exist / were modified as the plan described.
+- Tests pass.
+- No `// TODO(bundle):` markers remain in the modified files for that
+  member.
+
+If any member is not done, list it for the user and ask whether to
+proceed anyway (default: don't). If the user says yes, note in the shared
+summary that member `t:<id>` was bulk-completed despite incomplete
+verification.
+
+## Step 3: Append a completion summary to the plan (optional but recommended)
+
+If the bundle has a `planDir`, open the latest `plan*.md` and append at
+the bottom:
+
+```markdown
+## <ISO 8601 timestamp> — Completion
+
+<One paragraph summarizing what was implemented, which tests pass, and any
+deferred scope. Reference each member by t:<id> if behavior differed.>
+```
+
+## Step 4: Run the CLI
+
+```bash
+syntaur todo bundle complete <bundle-id> \
+  [--summary "<shared one-line summary>"] \
+  <scope flags>
+```
+
+The CLI flips every non-completed member to `completed`, clears its
+`session`, writes one log entry per newly-completed member, and bumps the
+bundle's `updatedAt`. Already-completed members are skipped silently.
+
+## Step 5: Confirm derived status
+
+```bash
+syntaur todo bundle show <bundle-id> <scope flags>
+```
+
+The `Status:` line should now read `completed (N/N done)`. If it reads
+`mixed`, some members were not in the expected state — surface to the user.
+
+## Step 6: Decide bundle disposition
+
+The CLI leaves the bundle record intact after `complete` for historical
+reference. The user has two options:
+
+- Leave the bundle intact (default). `bundle list` will keep showing it
+  with `completed` derived status. Plan + worktree remain on disk.
+- Dissolve via `syntaur todo bundle dissolve <bundle-id>` — clears each
+  member's `bundleId` back to `null` and removes the bundle from
+  `bundles/index.md`. Member status / planDir / branch / worktreePath are
+  preserved.
+
+Recommend leaving it intact unless the user explicitly wants to recycle
+the worktree / branch for unrelated work.
+
+## Step 7: Report to user
+
+- Bundle id.
+- Number of newly-completed members vs already-done.
+- Path to the shared summary appendix (if written).
+- Derived status from `bundle show`.
+- Suggested next: continue, dissolve, or grab a different bundle.
+
+## Step 8: Mirror skills (if you also edited the skill file)
+
+If this session also touched `skills/<name>/SKILL.md`, run:
+
+```bash
+npm run mirror-skills
+```

package/skills/grab-bundle/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: grab-bundle
+description: >-
+  Claim a Syntaur todo bundle (a lightweight container grouping 2+
+  scope-mate todos under a shared plan and worktree, with no full
+  assignment overhead). Use when the user wants to start working on a
+  todo bundle: "claim bundle b:xxxx", "work on the auth-cleanup bundle",
+  or after creating one via `syntaur todo bundle new`.
+license: MIT
+metadata:
+  author: prong-horn
+  version: "1.0.0"
+---
+
+# Grab Bundle
+
+Claim a Syntaur todo bundle and set up the current workspace. The bundle
+contract is lighter than an assignment — no lifecycle transitions, no
+progress.md, no handoff/decision-record/acceptance criteria. Member todos
+keep their own `start` / `complete` lifecycle; the bundle just owns the
+shared `planDir`, `branch`, `worktreePath`, and `repository`.
+
+## Input
+
+One or two positional arguments:
+
+- A bundle id (with or without `b:` prefix) — required if multiple bundles
+  exist in the current scope.
+- Scope flags: `--workspace <slug>`, `--project <slug>`, or `--global`
+  (default).
+
+If no id is given, run `syntaur todo bundle list <scope flags>` and ask
+the user to pick.
+
+## Pre-flight check
+
+Read `.syntaur/context.json` in the current working directory.
+
+- If it already contains assignment fields (`projectSlug`/`assignmentSlug`/
+  `assignmentDir`), warn the user: "You already have an active assignment.
+  Grabbing a bundle will replace this context. Proceed?" — stop if no.
+- If it already contains different bundle fields (`bundleId` set to a
+  different id), warn: "Context is bound to bundle b:<old>. Switch to b:<new>?"
+  — stop if no.
+- If it has only `sessionId` (platform SessionStart hook seeded it), proceed
+  and merge bundle fields on top.
+
+## Step 1: Load the bundle
+
+```bash
+syntaur todo bundle show <bundle-id> <scope flags>
+```
+
+Note its scope, member todos, slug, planDir (if any), branch (if any),
+worktreePath (if any), and repository.
+
+## Step 2: Read the bundle's plan (if present)
+
+If `planDir` is set, read `<planDir>/plan.md` (and any `plan-v<N>.md` —
+prefer the highest version). This is the shared implementation plan for
+the whole bundle.
+
+## Step 3: Read each member todo
+
+For each `[t:<id>]` listed in the bundle, run
+`syntaur todo list --status open` (and `--status in_progress` and
+`--status blocked`) under the same scope, OR read the checklist markdown
+directly. Note the description, current status, and any session
+fingerprint on `in_progress` members.
+
+## Step 4: Write bundle context.json
+
+Merge bundle fields into `<workspaceRoot>/.syntaur/context.json` — never
+overwrite. Required fields:
+
+```json
+{
+  "bundleId": "<bundle.id>",
+  "bundleSlug": "<bundle.slug or null>",
+  "bundleScope": "<workspace|project|global>",
+  "bundleScopeId": "<scopeId>",
+  "todoIds": ["<id1>", "<id2>", "..."],
+  "planDir": "<planDir or null>",
+  "branch": "<branch or null>",
+  "worktreePath": "<worktreePath or null>",
+  "repository": "<repository or null>",
+  "boundAt": "<ISO 8601>"
+}
+```
+
+NO assignment fields. The `resolveAssignmentTarget` discriminator at
+`src/utils/assignment-target.ts` will throw a clean error if any assignment
+flow misfires inside a bundle worktree.
+
+If the bundle already has a worktreePath set and the user is NOT inside it,
+suggest `cd <worktreePath>` before continuing.
+
+## Step 5: Report to user
+
+Summarize:
+
+- Bundle id (b:xxxx) + slug.
+- Scope + scopeId.
+- Number of members + their descriptions + statuses.
+- Plan file path (if any).
+- Branch + worktreePath (if any).
+- Repository (if any).
+- Suggested next step:
+  - `/plan-bundle` if no plan exists yet
+  - `/bundle-worktree --branch <name>` if no worktree exists yet
+  - `/complete-bundle` if every member is done

package/skills/plan-bundle/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: plan-bundle
+description: >-
+  Draft a shared implementation plan for the active Syntaur todo bundle.
+  Use when the user wants to plan a bundle, write or extend its plan.md,
+  or design an approach that covers every member todo together.
+license: MIT
+metadata:
+  author: prong-horn
+  version: "1.0.0"
+---
+
+# Plan Bundle
+
+Create or extend the bundle's shared plan file. Bundles are non-lifecycle-
+bearing containers — their "acceptance" is "every member todo is completed."
+The plan must surface this explicitly: there are no acceptance criteria of
+the bundle's own to track, only the member todos.
+
+## Step 1: Load context
+
+Read `.syntaur/context.json` from the current working directory. It must
+contain `bundleId` (a bundle context). If it instead has assignment fields,
+stop and tell the user: "Active context is an assignment, not a bundle.
+Use `/plan-assignment` instead, or `/grab-bundle <id>` to switch."
+
+Extract `bundleId`, `bundleScope`, `bundleScopeId`, `todoIds`, `planDir`.
+
+## Step 2: Read each member todo
+
+For each `t:<id>` in `todoIds`, read the description from the bundle's
+scope checklist:
+
+- workspace scope → `~/.syntaur/todos/<scopeId>.md`
+- global scope → `~/.syntaur/todos/_global.md`
+- project scope → `~/.syntaur/projects/<scopeId>/todos/<scopeId>.md`
+
+Note each member's current status. Bundled members can be `open`,
+`in_progress`, or `blocked` — a `completed` member should not be in a
+live bundle (run `syntaur doctor` if you see one).
+
+## Step 3: Create or open the plan file
+
+```bash
+syntaur todo bundle plan <bundle-id> <scope flags>
+```
+
+This prints the path to the new (or next-version) plan file. First call
+creates `plan.md`; subsequent calls create `plan-v2.md`, `plan-v3.md`, etc.
+The stub frontmatter includes `bundle:`, `todos:`, `scope:`, `status: draft`.
+A `## Members` section listing each member is pre-populated.
+
+## Step 4: Write the plan body
+
+Replace the body of the new plan file with:
+
+1. **Overview** — one paragraph: why these todos are bundled together (a
+   shared schema migration, a feature with split FE/BE work, a coordinated
+   refactor, etc.).
+2. **Tasks** — numbered list. For each task: description, files to
+   create/modify, dependencies on other tasks, complexity estimate.
+3. **Member Mapping** — for each `t:<id>` member, which numbered task(s)
+   complete it. This is the bundle equivalent of an assignment's "Acceptance
+   Criteria Mapping" — it tells the implementer "after task N is done,
+   member t:<id> can be marked completed."
+4. **Risks and Open Questions**.
+5. **Testing Strategy**.
+
+Bump `updated:` in the plan frontmatter and flip `status: draft` → `status: in_progress`.
+
+## Step 5: Mirror skills (if you also edited the skill file)
+
+If this session also added or edited any `skills/<name>/SKILL.md`, run:
+
+```bash
+npm run mirror-skills
+```
+
+This is per `AGENTS.md` — propagates to `platforms/<kind>/skills/`.
+
+## Step 6: Report to user
+
+- Plan file path (absolute).
+- Task count.
+- Open questions / risks worth flagging up front.
+- Suggested next step:
+  - `/bundle-worktree --branch <name>` to spin up the shared worktree
+  - Otherwise start implementing the first task in-place

package/dashboard/dist/assets/channel-CN5VmjNa.js

@@ -1 +0,0 @@
-import{aq as o,ar as n}from"./mermaid.core-B0Ixd1yP.js";const t=(r,a)=>o.lang.round(n.parse(r)[a]);export{t as c};

package/dashboard/dist/assets/classDiagram-VBA2DB6C-CqLb9GuU.js

@@ -1 +0,0 @@
-import{s as a,c as s,a as e,C as t}from"./chunk-WL4C6EOR-DZ3WYdab.js";import{_ as i}from"./mermaid.core-B0Ixd1yP.js";import"./chunk-FMBD7UC4-7RuZ6HEq.js";import"./chunk-JSJVCQXG-B5dwG0bv.js";import"./chunk-55IACEB6-cKEeGDNI.js";import"./chunk-KX2RTZJC-DeyQYDVj.js";import"./index-D7UtkCYM.js";var n={parser:e,get db(){return new t},renderer:s,styles:a,init:i(r=>{r.class||(r.class={}),r.class.arrowMarkerAbsolute=r.arrowMarkerAbsolute},"init")};export{n as diagram};

package/dashboard/dist/assets/classDiagram-v2-RAHNMMFH-CqLb9GuU.js

@@ -1 +0,0 @@
-import{s as a,c as s,a as e,C as t}from"./chunk-WL4C6EOR-DZ3WYdab.js";import{_ as i}from"./mermaid.core-B0Ixd1yP.js";import"./chunk-FMBD7UC4-7RuZ6HEq.js";import"./chunk-JSJVCQXG-B5dwG0bv.js";import"./chunk-55IACEB6-cKEeGDNI.js";import"./chunk-KX2RTZJC-DeyQYDVj.js";import"./index-D7UtkCYM.js";var n={parser:e,get db(){return new t},renderer:s,styles:a,init:i(r=>{r.class||(r.class={}),r.class.arrowMarkerAbsolute=r.arrowMarkerAbsolute},"init")};export{n as diagram};

package/dashboard/dist/assets/clone-DwvrjCQs.js

@@ -1 +0,0 @@
-import{b as r}from"./_baseUniq-BjbISCNN.js";var e=4;function a(o){return r(o,e)}export{a as c};