schub 0.1.21 → 0.1.23

package/drizzle/meta/_journal.json

@@ -8,6 +8,27 @@
       "when": 1770925849551,
       "tag": "0000_salty_champions",
       "breakpoints": true
+    },
+    {
+      "idx": 1,
+      "version": "6",
+      "when": 1770989495517,
+      "tag": "0001_quick_prowler",
+      "breakpoints": true
+    },
+    {
+      "idx": 2,
+      "version": "6",
+      "when": 1771408222359,
+      "tag": "0002_closed_tyrannus",
+      "breakpoints": true
+    },
+    {
+      "idx": 3,
+      "version": "6",
+      "when": 1771410443593,
+      "tag": "0003_heavy_scrambler",
+      "breakpoints": true
     }
   ]
 }

package/package.json

@@ -1,7 +1,10 @@
 {
   "name": "schub",
-  "version": "0.1.21",
+  "version": "0.1.23",
   "type": "module",
+  "imports": {
+    "#services": "./src/services.ts"
+  },
   "bin": {
     "schub": "./dist/index.js"
   },
@@ -17,10 +20,11 @@
     "prepublishOnly": "bun run build:bundle",
     "build": "bun build ./src/index.ts --outfile dist/index.js --target node --banner \"#!/usr/bin/env node\"",
     "build:bundle": "bun run build && bun run build:services && bun run build:dashboard && bun run build:api",
-    "build:services": "bun build ../../packages/schub-services/src/index.ts --outfile dist/services/runtime.js --target node --external better-sqlite3",
+    "build:services": "bun build ./src/services.ts --outfile dist/services/runtime.js --target node --external better-sqlite3",
     "build:dashboard": "bun run --cwd ../../dashboard build && rm -rf dist/dashboard && cp -r ../../dashboard/dist dist/dashboard",
-    "build:api": "bun build ../../packages/schub-api/src/server.ts --outfile dist/api/server.js --target node --external better-sqlite3 && rm -rf drizzle && cp -r ../../packages/schub-services/drizzle drizzle",
-    "lint": "bunx @biomejs/biome lint .",
+    "build:api": "bun build ../../packages/schub-api/src/server.ts --outfile dist/api/server.js --target node --external better-sqlite3 && rm -rf drizzle && cp -r ../../packages/schub-db/drizzle drizzle",
+    "typecheck": "bunx tsc --noEmit",
+    "lint": "bun run typecheck && bunx @biomejs/biome lint .",
     "format": "bunx @biomejs/biome format --write .",
     "test": "bun test"
   },
@@ -40,7 +44,9 @@
     "yargs": "^18.0.0"
   },
   "devDependencies": {
-    "@pstdio/schub-services": "workspace:*",
+    "@pstdio/schub-agents": "workspace:*",
+    "@pstdio/schub-db": "workspace:*",
+    "@pstdio/schub-storage": "workspace:*",
     "@types/bun": "latest",
     "@types/marked-terminal": "^6.0.0",
     "@types/node": "^24.3.0",

package/skills/create-proposal/SKILL.md

@@ -12,17 +12,17 @@ $ARGUMENTS
 ## Workflow
 
 1. Derive a concise, verb-led `title` from the request (kebab-case: `add-`, `update-`, `remove-`, `refactor-`, `fix-`).
-2. Run `npx schub proposals create --title "<title>" --input "<user prompt verbatim>"` to scaffold the proposal template.
+2. Run `npx schub proposals write --title "<title>" --input "<user prompt verbatim>"` to scaffold the proposal template.
    - Treat the scaffolded file as temporary while drafting the proposal.
    - Supported flags: `--title`, `--input`, `--overwrite`.
 3. Capture the generated proposal-id from the command output or the created path under `.schub/proposals/<proposal-id>/`.
 4. Update the generated proposal with concrete, testable statements.
 5. Identify the touch points throughout the project and track them in the proposal.
 6. Track missing information with [MISSING INFORMATION] tags in the proposal.
-7. (OPTIONAL) If the change affects a public surface, e.g. an api / sdk / cli. Run `npx schub cookbook create --proposal-id "<proposal-id>"` to scaffold `cookbook.md`.
+7. (OPTIONAL) If the change affects a public surface, e.g. an api / sdk / cli. Run `npx schub templates create --name "cookbook" --proposal-id "<proposal-id>"` to scaffold `cookbook.md`.
 8. (OPTIONAL) If implementing the change requires knowledge of an api / db schema etc. encode this in a `contracts.md` or `schemas.md` files.
 9. (OPTIONAL) For complex tickets requiring deep understanding of the system, track relevant additional information in `research.md`.
-10. (OPTIONAL) For decisions with lasting architectural impact or important tradeoffs, run `npx schub adr create --proposal-id "<proposal-id>" --title "<title>"`.
+10. (OPTIONAL) For decisions with lasting architectural impact or important tradeoffs, run `npx schub templates create --name "adr" --proposal-id "<proposal-id>" --title "<title>"`.
 11. Run `npx schub proposals save --proposal-id "<proposal-id>"` to persist the final proposal and related files under `.schub/proposals/<proposal-id>/` (proposal, cookbook, schemas, contracts, research, adr).
 
 ## Output Locations

package/skills/create-ticket/SKILL.md

@@ -15,7 +15,7 @@ $ARGUMENTS
    - If the user explicitly asked to create a ticket, set status to `backlog`.
    - Otherwise set status to `wip`.
 2. Derive a concise, verb-led ticket title from the user request and immediately run the schub CLI to create the ticket.
-   - Run `npx schub tickets create --title "<ticket title>" --input "<user prompt verbatim>" --status "<status>"`.
+   - Run `npx schub tickets write --title "<ticket title>" --input "<user prompt verbatim>" --status "<status>"`.
    - If the ticket maps to a proposal, include `--proposal-id "<shorthand>"`.
 3. Fill the ticket template with concrete details:
    - Priority (P1/P2/P3)

package/skills/create-tickets-for-proposal/SKILL.md

@@ -12,7 +12,7 @@ $ARGUMENTS
 ## Workflow
 
 1. Load the proposal files locally (they may not exist yet):
-   - Run `npx schub proposals load --proposal-id "<shorthand>"`.
+   - Run `npx schub proposals pull --proposal-id "<shorthand>"`.
 2. Confirm `.schub/proposals/<proposal-id>/proposal.md` exists and that it is marked accepted. If it is missing, ask the user to run the create-proposal skill first. If it is still a draft, ask the user to review it first.
 3. Read the proposal and other files in the `<proposal-id>` folder.
 4. Derive tickets, each ticket should be:
@@ -24,7 +24,7 @@ $ARGUMENTS
    - Include `Acceptance` criteria with explicit tests (file paths, cases covered) and exact commands to run.
    - Include corresponding documentation updates.
 5. Create tickets via the CLI (one command per ticket).
-   - Run `npx schub tickets create --title "<ticket title>" --proposal-id "<shorthand>" --status "<status>"`.
+   - Run `npx schub tickets write --title "<ticket title>" --proposal-id "<shorthand>" --status "<status>"`.
 6. Fill the ticket template with concrete details:
    - Priority (P1/P2/P3)
    - Parallelizable (yes/no)

package/skills/implement-ticket/SKILL.md

@@ -13,11 +13,10 @@ $ARGUMENTS
 
 ## Workflow
 
-1. (Optional) If the ticket description is missing, load it:
-   - If unclear or missing, ask for **one**: ticket id (kebab-case), or `next`.
-   - If `next` / `continue`: run `npx schub tickets list --status ready --json`, then pick the first ticket by id order.
-   - Otherwise run `npx schub tickets pull --id <shorthand>`.
-   - If none found, ask the user to confirm the ticket id.
+1. (Optional) If no ticket description is provided:
+   - If `next` / `continue`: run `npx schub tickets list --status ready --json`, then pull the first ticket by id.
+   - If valid id: run `npx schub tickets pull --id <shorthand>`.
+   - If the ticket is missing, ask the user to confirm the ticket id or `next`.
 2. Update the ticket status
    - When starting work, run: `npx schub tickets update --id "<ticket-id>" --status wip`.
    - If blocked: run `npx schub tickets update --id "<ticket-id>" --status blocked --blocked-reason <reason>` and stop the workflow.
@@ -47,14 +46,14 @@ $ARGUMENTS
    - If tests/commands can’t be run, record why in `## Evidence`.
 6. Finish
    - Confirm everything in `## Steps` and `## Acceptance` is checked.
-   - If the ticket is not completed due to errors, run `npx schub tickets update --id "<ticket-id>" --status blocked --blocked-reason <reason>`, then run `npx schub ticket save --id "<ticket-id>"`.
+   - If the ticket is not completed due to errors, run `npx schub tickets update --id "<ticket-id>" --status blocked --blocked-reason <reason>`, then run `npx schub tickets save --id "<ticket-id>"`.
    - If the ticket is completed, run `npx schub tickets update --id "<ticket-id>" --status in_review`.
    - Commit the implementation changes before handing off, including ticket updates and evidence references.
    - Report completed files and artifacts.
 
 ## Validation
 
-To be considered complete and ready for review, a ticket should provide Validation Artifacts. Validation Artifacts are **verifiable outputs** produced while doing the ticket e.g. by running `some_command &> some-logs.txt`
+To be considered complete and ready for review, a ticket should provide Validation Artifacts. Validation Artifacts are **verifiable outputs** produced while doing the ticket e.g. by running `<validation-command> > validation.log 2>&1`
 
 Agents should dump and review artifacts, including:
 

package/skills/review-proposal/SKILL.md

@@ -3,7 +3,7 @@ name: review-proposal
 description: "Run a review session for a proposal by creating a list of open questions, updating the proposal, adding a Q&A section, and deleting REVIEW_ME.md on completion. Use when asked to review proposals."
 ---
 
-## User Input (proposal-id or shorthand `C####`)
+## User Input (proposal-id or shorthand `P####`)
 
 ```text
 $ARGUMENTS
@@ -12,10 +12,10 @@ $ARGUMENTS
 ## Workflow
 
 1. Load the proposal files locally (they may not exist yet):
-   - Run `npx schub proposals load --proposal-id "<shorthand>"`.
+   - Run `npx schub proposals pull --proposal-id "<shorthand>"`.
 2. Confirm `.schub/proposals/<proposal-id>/proposal.md` exists. If it is missing, ask the user to run the create-proposal skill first. If it is still a draft, ask the user to review it first.
 3. Review the proposal by checking the [MISSING INFORMATION] tags and the potential issues listed.
-4. If there are issues, or missing information, run `npx schub review create --proposal-id "<proposal-id>"` to scaffold `.schub/proposals/<proposal-id>/REVIEW_ME.md`.
+4. If there are issues, or missing information, run `npx schub templates create --name "review" --proposal-id "<proposal-id>"` to scaffold `.schub/proposals/<proposal-id>/REVIEW_ME.md`.
 5. Triage each item:
    - **High-stakes** (scope, risks, dependencies, security, performance): create a bullet point item in the review checklist.
    - **Minute details** (naming, copy, formatting, low-impact defaults): make a decision update the proposal and mark as an assumption in the proposal.

package/templates/create-proposal/cookbook-template.md

@@ -1,5 +1,5 @@
 ---
-change_id: "{{CHANGE_ID}}"
+proposal_id: "{{PROPOSAL_ID}}"
 created: "{{DATE}}"
 ---
 

package/templates/create-proposal/proposal-template.md

@@ -1,5 +1,5 @@
 ---
-change_id: "{{CHANGE_ID}}"
+proposal_id: "{{PROPOSAL_ID}}"
 created: "{{DATE}}"
 status: Draft
 input: "{{INPUT}}"

package/templates/create-tasks/task-template.md

@@ -1,5 +1,5 @@
 ---
-change_id: "{{CHANGE_ID}}"
+proposal_id: "{{PROPOSAL_ID}}"
 priority: "[P1|P2|P3]"
 depends_on: []
 parallelizable: "[no|yes]"

package/templates/create-ticket/ticket-template.md

@@ -3,7 +3,7 @@ ticket_id: "{{TICKET_ID}}"
 created: "{{DATE}}"
 status: "{{STATUS}}"
 input: "{{INPUT}}"
-change_id: "{{CHANGE_ID}}"
+proposal_id: "{{PROPOSAL_ID}}"
 priority: "[P1|P2|P3]"
 complexity: "[low|medium|high]"
 depends_on: []

package/templates/review-proposal/q&a-template.md

@@ -1,5 +1,5 @@
 ---
-change_id: "{{CHANGE_ID}}"
+proposal_id: "{{PROPOSAL_ID}}"
 created: "{{DATE}}"
 ---
 

package/templates/review-proposal/review-me-template.md

@@ -1,5 +1,5 @@
 ---
-change_id: "{{CHANGE_ID}}"
+proposal_id: "{{PROPOSAL_ID}}"
 created: "{{DATE}}"
 ---