syntaur 0.5.3 → 0.6.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "syntaur",
-  "version": "0.5.3",
+  "version": "0.6.0",
   "description": "Project workflow CLI with dashboard, Claude Code plugin, and Codex plugin",
   "homepage": "https://github.com/prong-horn/syntaur#readme",
   "repository": {

package/vendor/syntaur-skills/README.md

@@ -43,8 +43,10 @@ npx skills add prong-horn/syntaur-skills --skill syntaur-protocol
 | `grab-assignment` | Discover and claim a pending assignment from a project. Sets up working context. |
 | `plan-assignment` | Create a detailed implementation plan for the current assignment. |
 | `complete-assignment` | Write a handoff and transition an assignment to review or completed. |
+| `clear-assignment` | Drop the active assignment from session context without transitioning lifecycle state. Inverse of `grab-assignment`. |
 | `create-project` | Create a new project with full scaffolding (manifest + indexes + resources + memories). |
 | `create-assignment` | Create a new assignment within a project (or as a standalone one-off at `~/.syntaur/assignments/<uuid>/`). |
+| `manage-statuses` | List / add / rename / remove / reorder custom assignment statuses (and transitions); writes to `~/.syntaur/config.md`. |
 
 ## How it works
 

package/vendor/syntaur-skills/skills/clear-assignment/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: clear-assignment
+description: >-
+  Clear the active Syntaur assignment from the current session without
+  transitioning lifecycle state. Use when the user wants to drop, release,
+  unclaim, abandon, or clear assignment context — e.g., "clear my assignment",
+  "drop this assignment", "release context", "unclaim this", "I'm not actually
+  working on this anymore". Does not mark the assignment complete or failed.
+license: MIT
+metadata:
+  author: prong-horn
+  version: "1.0.0"
+---
+
+# Clear Assignment
+
+Drop the active assignment binding from the current workspace. The assignment itself is left untouched in `~/.syntaur/projects/.../assignments/` — only the local `.syntaur/context.json` pointer is cleared so the session is no longer scoped to it.
+
+This is the inverse of `grab-assignment`. Unlike `complete-assignment`, it does **not** transition lifecycle state, write a handoff, or close out the work. Use it when:
+
+- The user grabbed the wrong assignment.
+- The user wants to switch focus without finishing or formally reviewing the current one.
+- Session context was set up earlier and is now stale.
+
+If the assignment is actually done, use `complete-assignment` instead so a handoff is recorded and the lifecycle state advances.
+
+## Input
+
+Optional flags from the user:
+
+- `--keep-session` — preserve `sessionId` / `transcriptPath` fields in `context.json` (just strip the assignment fields). Default: full delete.
+- `--unassign` — also run `syntaur unassign <slug> --project <project>` so the assignment is no longer claimed by this agent. Default: leave the claim in place (only the local context is cleared). Skip this flag if the CLI does not support `unassign` in the installed version — fall back to leaving the claim alone and tell the user.
+
+## Step 1: Load Context
+
+Read `.syntaur/context.json` from the current working directory.
+
+- If the file does not exist, tell the user: "No active assignment context to clear." and stop.
+- If the file exists but contains only session fields (`sessionId`, `transcriptPath`) and no `projectSlug` / `assignmentSlug`, tell the user: "No active assignment is bound — only a platform session record exists. Nothing to clear." and stop (unless they explicitly ask to wipe the session record too).
+
+Otherwise extract: `projectSlug`, `assignmentSlug`, `assignmentDir`, `title`.
+
+## Step 2: Confirm with the User
+
+Show the user what is about to be cleared and confirm before touching anything:
+
+> About to clear active assignment context:
+> - Assignment: `<assignmentSlug>` — <title>
+> - Project: `<projectSlug>` (or "standalone" if null)
+> - The assignment itself will NOT be transitioned. Its lifecycle status stays as-is.
+> - Proceed?
+
+Stop if the user says no.
+
+If lifecycle status is `in_progress` and the user has not passed `--complete-instead`, also note:
+
+> Note: this assignment is currently `in_progress`. Clearing context does not change that. If you actually finished it, run `complete-assignment` instead so a handoff is recorded.
+
+## Step 3 (optional): Unassign
+
+If the user passed `--unassign`, run:
+
+```bash
+syntaur unassign <assignment-slug> --project <project-slug>
+```
+
+For standalone assignments use the UUID (the folder name) in place of the slug, and omit `--project`.
+
+If the CLI rejects the command (older versions may not implement `unassign`), report the error and continue — the local context clear in Step 4 still happens.
+
+## Step 4: Clear the Context File
+
+Default behavior — delete the file entirely:
+
+```bash
+rm .syntaur/context.json
+```
+
+If the user passed `--keep-session`, preserve session fields and strip everything else instead:
+
+```bash
+jq '{sessionId, transcriptPath} | with_entries(select(.value != null))' \
+  .syntaur/context.json > .syntaur/context.json.tmp \
+  && mv .syntaur/context.json.tmp .syntaur/context.json
+```
+
+If the resulting file would be empty (`{}`), delete it instead of leaving an empty stub.
+
+Do not delete the `.syntaur/` directory itself — other tooling may use it.
+
+## Step 5: Close Session (optional)
+
+If the original `context.json` included a `sessionId` and the Syntaur dashboard is running, mark the session as cleared so the dashboard does not keep showing it as active:
+
+```bash
+curl -s -X PATCH "http://localhost:$(cat ~/.syntaur/dashboard-port 2>/dev/null || echo 4800)/api/agent-sessions/<session-id>/status" \
+  -H "Content-Type: application/json" \
+  -d '{"status":"cleared","projectSlug":"<project-slug>"}'
+```
+
+If this fails (e.g., dashboard not running, endpoint not present in the installed version), it is non-critical — silently continue.
+
+Skip this step entirely when `--keep-session` is set.
+
+## Step 6: Report to User
+
+Summarize:
+- Which assignment was cleared (slug + title).
+- That its lifecycle status is unchanged (and what that status currently is, if known from frontmatter).
+- Whether the assignment was unassigned via the CLI or the claim was left in place.
+- Suggested next step: `grab-assignment` to claim a different one, or `complete-assignment` if the previous one was actually finished.

package/vendor/syntaur-skills/skills/manage-statuses/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: manage-statuses
+description: >-
+  Manage custom assignment statuses and transitions in Syntaur. Use when the
+  user wants to add a status, customize a workflow stage, rename a status,
+  remove or reorder statuses, define a custom transition, change which states
+  are terminal (the "done state"), or otherwise edit the `statuses:` block in
+  `~/.syntaur/config.md`. Triggers on phrases like "add a status", "custom
+  status", "rename a status", "workflow stage", "change my workflow",
+  "terminal status", "done state".
+license: MIT
+metadata:
+  author: prong-horn
+  version: "1.0.0"
+---
+
+# Manage Statuses
+
+Customize Syntaur's assignment-status workflow via the `syntaur status` CLI. The CLI writes to the same `statuses:` block in `~/.syntaur/config.md` that the dashboard Settings page edits — so CLI and dashboard edits stay in sync.
+
+The runtime is **all-or-nothing**: once `~/.syntaur/config.md` has a `statuses:` block, the built-in defaults (`pending`, `in_progress`, `blocked`, `review`, `completed`, `failed`) are NOT merged. `syntaur status init` materializes those defaults explicitly so the user has a starting point to customize. `syntaur status reset` removes the block to revert.
+
+## Input
+
+The user usually describes the change in free-form prose ("add a needs-design status after pending", "rename in_progress to working", "remove blocked", "make completed not terminal"). Map their intent to a subcommand:
+
+| Subcommand | When to use |
+|-----------|-------------|
+| `syntaur status list [--json]` | Show the current set, with `source: config | default` markers. Always run this first when the user asks "what statuses do I have?" |
+| `syntaur status init [--force]` | Materialize the built-in defaults explicitly. Run before any custom edit if `list` shows `source: default` for everything. |
+| `syntaur status reset [--force]` | Remove the `statuses:` block and revert to implicit defaults. |
+| `syntaur status add <id> --label <label> [--color <hex>] [--icon <name>] [--description <text>] [--terminal] [--after <id> | --before <id> | --at-end]` | Append a new status. Position flags are mutually exclusive. |
+| `syntaur status set --id <id> [...]` | Mutate metadata on an existing status without renaming. `--terminal true|false` (literal strings). |
+| `syntaur status reorder <id,id,...>` | Replace the order array. CSV must be a permutation of current ids — no drops, no extras. |
+| `syntaur status remove <id> [--force]` | Remove a status. Without `--force`, errors if any assignment references it; lists offenders. With `--force`, also prunes `order` and `transitions[i]` whose `from === <id>` or `to === <id>`. |
+| `syntaur status rename <id> --to <new-id> [--label <label>]` | Rename a status id. **Atomic** rewrite across `config.md` + every affected `assignment.md`. Without `--label`, keeps the original label. |
+| `syntaur status transition add --from <id> --command <cmd> --to <id> [--label <label>] [--requires-reason]` | Define a custom transition. |
+| `syntaur status transition remove --from <id> --command <cmd>` | Drop a custom transition. |
+
+Every mutating subcommand supports `--dry-run`, which prints a unified diff of the would-be `statuses:` block change (and, for `rename`, a per-file frontmatter diff for each affected `assignment.md`) and exits without writing.
+
+## Step 1: Determine intent → pick subcommand
+
+Read the user's request and choose the subcommand. If ambiguous, ask. If the user says "make my workflow look like X", run `syntaur status list` first, present what's there, and confirm what they actually want changed.
+
+If the user is making a destructive change (`remove`, `rename`, `reset`), default to running with `--dry-run` first and showing the diff, then asking the user to confirm before re-running without `--dry-run`.
+
+## Step 2: Run the CLI
+
+Build and run the chosen `syntaur status ...` invocation. Quote labels and descriptions that contain spaces. Use the literal strings `true`/`false` for `--terminal` on the `set` subcommand.
+
+If the user is on a fresh `~/.syntaur/config.md` (no `statuses:` block) and wants to make any change other than `init`/`reset`, run `syntaur status init` first so subsequent `add` / `set` / `reorder` / `rename` / `remove` operate on an explicit set.
+
+## Step 3: Verify with `syntaur status list`
+
+After every mutating subcommand, run `syntaur status list` (or `--json` for machine consumption) and confirm the change took effect. Report back to the user with the new state.
+
+## Step 4: Guide next steps
+
+- **If the dashboard is running** (`syntaur dashboard`), tell the user to restart it. The dashboard caches `StatusConfig` per-process and CLI mutations cannot reach a separate Node process. The dashboard's own writes invalidate its cache automatically; CLI writes don't.
+- **After a `rename`,** every assignment that referenced the old id has been rewritten in-place. Mention this to the user — git will show diffs in many `assignment.md` files. They are intentional.
+- **After a `remove --force`,** the affected assignments now reference an undefined status. `syntaur doctor` will flag them as invalid. Suggest the user run `syntaur doctor` and either re-add the status (`syntaur status add ...`) or edit each frontmatter to a valid id.
+- **After `transition add`,** the dashboard's transition buttons reflect the new transition only after the cache invalidation above.
+
+## Safety notes
+
+- **`remove` is destructive.** Without `--force` it refuses if any assignment references the id. Don't suggest `--force` without first running `syntaur status remove <id>` (no force) so the user sees the affected list.
+- **`rename` rewrites many files.** It edits `config.md` AND every affected `assignment.md` in a single atomic transaction (with rollback if any write fails partway). Always run `--dry-run` first on a non-trivial codebase so the user sees the per-file diff.
+- **`terminal: true` is load-bearing.** Terminal statuses affect dashboard progress bars and dependency-satisfaction logic — an assignment with a terminal status counts as "done" for downstream `dependsOn` checks and project-rollup status. Don't toggle this on `pending`-style states without thinking.
+- **`init --force` overwrites a custom block.** Use `reset` first if the user wants a clean slate, OR confirm before passing `--force` if they have unsaved customizations.
+- **Concurrency.** `rename`'s buffer-write-rollback strategy assumes no concurrent writers. Tell the user to close the dashboard / pause other agents during a rename.
+- **`SYNTAUR_HOME` precedence.** If the user has `SYNTAUR_HOME` set, the CLI writes there instead of `~/.syntaur`. Mirror their environment.

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

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

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

@@ -1 +0,0 @@
-import{s as a,c as s,a as e,C as t}from"./chunk-WL4C6EOR-sYE1pmwc.js";import{_ as i}from"./mermaid.core-kxfDb1ct.js";import"./chunk-FMBD7UC4-DDGrEm9o.js";import"./chunk-JSJVCQXG-DQDIUaJ5.js";import"./chunk-55IACEB6-BRicQJbU.js";import"./chunk-KX2RTZJC-s54oa7En.js";import"./index-DabqR6PW.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-CZUrPM07.js

@@ -1 +0,0 @@
-import{s as a,c as s,a as e,C as t}from"./chunk-WL4C6EOR-sYE1pmwc.js";import{_ as i}from"./mermaid.core-kxfDb1ct.js";import"./chunk-FMBD7UC4-DDGrEm9o.js";import"./chunk-JSJVCQXG-DQDIUaJ5.js";import"./chunk-55IACEB6-BRicQJbU.js";import"./chunk-KX2RTZJC-s54oa7En.js";import"./index-DabqR6PW.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-Dv7yV4O2.js

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