goalbuddy 0.2.20 → 0.2.22

package/README.md

@@ -70,7 +70,11 @@ GoalBuddy uses four primitives:
 - **Task**: exactly one active Scout, Judge, Worker, or PM task.
 - **Receipt**: compact proof for every completed, blocked, or escalated task.
 
-The default agents are installed with the skill:
+GoalBuddy bundles default agent templates. `$goal-prep` records whether matching installed agent configs were actually found; if not, `/goal` can continue through PM fallback, or you can install dedicated agents with:
+
+```bash
+npx goalbuddy agents
+```
 
 - **Scout** maps repo evidence, workflows, constraints, risks, and candidate next tasks.
 - **Judge** resolves ambiguity, scope, risk, task selection, and completion claims.
@@ -84,11 +88,7 @@ Install and enable the native Codex plugin:
 npx goalbuddy
 ```
 
-Restart Codex, then use `$goal-prep`. To add the optional extension bundle:
-
-```bash
-npx goalbuddy extend install --all
-```
+Restart Codex, then use `$goal-prep`. GoalBuddy ships with two visual board backends by default: a local live board and a GitHub Projects sync.
 
 If you prefer a global executable, install the npm package globally and run `goalbuddy`:
 
@@ -124,6 +124,12 @@ Check the local install:
 npx goalbuddy doctor
 ```
 
+Check whether a newer GoalBuddy release is available:
+
+```bash
+npx goalbuddy check-update
+```
+
 Use a non-default Codex home:
 
 ```bash
@@ -177,14 +183,14 @@ tasks:
 
 ## Extensions
 
-The npm package is the stable core. Optional extensions live under `extend/` and are discovered from the GitHub-hosted `extend/catalog.json`, so users do not need a new npm release for every integration.
+The npm package is the stable core. Local Board and GitHub Projects are bundled into the installed GoalBuddy skill so `$goal-prep` can offer a visual board immediately. Other optional extensions live under `extend/` and are discovered from the GitHub-hosted `extend/catalog.json`, so users do not need a new npm release for every integration.
 
 ```bash
+npx goalbuddy board docs/goals/<slug>
+npx goalbuddy extend github-projects
 npx goalbuddy extend
 npx goalbuddy extend github-pr-workflow
 npx goalbuddy extend install github-pr-workflow --dry-run
-npx goalbuddy extend install --all --dry-run
-npx goalbuddy extend install --all
 ```
 
 `goalbuddy extend` shows available extensions and detail commands. `goalbuddy extend <id>` shows local install state, activation state, credential requirements, safe-by-default status, and missing environment variables.
@@ -193,6 +199,7 @@ Current catalog examples include:
 
 - `github-pr-workflow`: prepares receipt-aligned commit and PR handoff text.
 - `github-projects`: mirrors GoalBuddy boards into GitHub Projects.
+- `local-goal-board`: serves a local live board that updates from `state.yaml` and `notes/`.
 - `ai-diff-risk-review`: summarizes risk in the current diff.
 - `ci-failure-triage`: maps failing CI back to likely causes and next tasks.
 - `docs-drift-audit`: checks whether docs still match implementation.

package/goalbuddy/SKILL.md

@@ -24,19 +24,37 @@ There are two different modes:
 
 This boundary is strict. `$goal-prep` is not a lightweight `/goal`; it is a board compiler.
 
-During a `$goal-prep` turn, do not perform the user's requested work, even if the work looks read-only, preparatory, or obviously useful. Do not refresh or load named skills, inspect implementation files, browse reference repos, research design inspiration, generate design plans, generate images/assets, run app-specific checks, start servers, or edit product files. Put those actions into Scout, Judge, Worker, or PM tasks for the later `/goal` run.
+During a `$goal-prep` turn, do not perform the user's requested work, even if the work looks read-only, preparatory, or obviously useful. Do not refresh or load named skills, inspect implementation files, browse reference repos, research design inspiration, generate design plans, generate images/assets, run app-specific checks, or edit product files. Put those actions into Scout, Judge, Worker, or PM tasks for the later `/goal` run.
 
 Allowed `$goal-prep` actions:
 
+- run the bundled GoalBuddy update checker and mention a newer version if one is available;
 - ask diagnostic intake questions and wait when required;
-- create or repair only `docs/goals/<slug>/goal.md`, `docs/goals/<slug>/state.yaml`, and `docs/goals/<slug>/notes/`;
+- create or repair only `docs/goals/<slug>/goal.md`, `docs/goals/<slug>/state.yaml`, `docs/goals/<slug>/notes/`, and the generated `.goalbuddy-board/` visual board artifact;
+- create and open the selected visual board surface for the goal;
 - optionally run the GoalBuddy board checker against that `state.yaml`;
-- verify that the GoalBuddy agents are installed, if this can be done without touching implementation work;
+- verify GoalBuddy agent availability, if this can be done without touching implementation work, and record `installed`, `bundled_not_installed`, `missing`, or `unknown` truthfully;
 - print exactly `/goal Follow docs/goals/<slug>/goal.md.`;
 - ask whether to start `/goal`, refine the board, or stop.
 
 If the prompt names another skill or tool, such as "use the taste skill", "refresh the taste skill", "look at this repo", "use browser", or "generate assets", record that requirement in the charter and seed tasks. Do not load that skill, browse that repo, or generate those assets during `$goal-prep`.
 
+## Update Check
+
+At the start of a `$goal-prep` turn, check whether GoalBuddy itself is stale. Run the bundled checker from the installed skill directory when available:
+
+```bash
+node <skill-path>/scripts/check-update.mjs --json
+```
+
+If the checker reports `update_available: true`, tell the user once before continuing:
+
+```text
+GoalBuddy <latest_version> is available. After this turn, update with: npx goalbuddy
+```
+
+Do not block intake or board creation on update checking. If the checker is missing, cannot find npm, or network access fails, continue silently unless the user asked about updates.
+
 ## Intake Compiler
 
 Before creating, repairing, or running a board, privately translate the user's input into a Goal Intake. The input may be vague, specific, or detailed with an existing plan. Do not dump the intake to the user unless they ask for it.
@@ -55,6 +73,22 @@ Extract:
 - blind spots: important risks, choices, or success dimensions the user may not have named yet;
 - existing plan facts: user-provided steps, files, constraints, or sequencing that must be preserved but still validated.
 
+Ask the visual-board question early, before detailed task shaping:
+
+```text
+Do you want to set up a visual board for this?
+```
+
+Recommended options:
+
+1. Local live board in Codex (Recommended) - starts immediately, requires no credentials, and lets the user watch tasks populate.
+2. GitHub Projects - best when stakeholders need a shared external board and the user can approve GitHub credentials/project details.
+3. No visual board - best for quick or private goals where the file board is enough.
+
+If the user chooses the local live board, create the goal directory, `notes/`, and an initial minimal `state.yaml` as soon as the slug is known, then run `npx goalbuddy board docs/goals/<slug>` and open the printed local URL in the Codex in-app Browser. In short: start the local board before filling the task list so the board pops up right away and cards populate live as `state.yaml` changes. Keep the printed URL in the final prep response as a fallback, but do not make the URL the primary experience.
+
+If the user chooses GitHub Projects, ask for approval and the required project target before any live write. Create or sync the GitHub Project at the same early point as the local board: after the goal root and skeleton `state.yaml` exist, before the detailed task list is finished, then sync again as tasks populate. Run a dry-run sync first when possible. Missing GitHub credentials or project details should not block local board creation or goal prep; record the missing requirement in `visual_board.github_projects` and seed a PM setup task.
+
 Ask before board creation when the request is vague, strategic, improvement-oriented, or open-ended and the user has not explicitly said to use defaults. Ask one guided question at a time with 2-3 options and a recommended default, then wait. Continue the diagnostic intake until the user's answers are sufficient to choose the board shape. Do not create or repair `docs/goals/<slug>/` until the diagnostic intake is complete or the user explicitly accepts defaults.
 
 For vague or strategic goals, one answer is rarely enough. After each answer, reflect what it implies, name one likely blind spot, and ask the next material question. The goal is to help the user discover what they mean, not merely collect a form value.
@@ -100,10 +134,11 @@ Stop after each question. Do not create files, repair an existing board, run che
 
 Minimum diagnostic ladder for vague, strategic, or improvement-oriented goals:
 
-1. Intent target: what kind of improvement or outcome matters most?
-2. Success proof: what evidence would convince the user this worked?
-3. Scope and non-goals: what should remain untouched or explicitly out of scope?
-4. Board handling: reuse an existing board, create a fresh board, or inspect first?
+1. Visual board: ask "Do you want to set up a visual board for this?"
+2. Intent target: what kind of improvement or outcome matters most?
+3. Success proof: what evidence would convince the user this worked?
+4. Scope and non-goals: what should remain untouched or explicitly out of scope?
+5. Board handling: reuse an existing board, create a fresh board, or inspect first?
 
 Ask these one at a time. Skip a step only when the user's words already answer it clearly. After the user answers one step, do not assume the remaining steps; ask the next unresolved material question.
 
@@ -131,15 +166,17 @@ When invoked directly, run intake first. For vague, strategic, improvement-orien
 
 Do:
 
+- check for a newer GoalBuddy version once at the start and mention it without blocking;
 - clarify or infer the goal title and slug;
 - run the Intake Compiler;
 - ask diagnostic intake questions when clarity would materially improve the board;
 - classify the goal as `specific`, `open_ended`, `existing_plan`, `recovery`, or `audit`;
 - create or repair `docs/goals/<slug>/`;
 - create `goal.md`, `state.yaml`, and `notes/`;
+- if requested, start the local visual board immediately and open it in the Codex in-app Browser before filling the task list;
 - seed a role-tagged task board that matches the input shape;
 - make the first active task safe;
-- verify Scout, Worker, and Judge agents are installed or explain what is missing;
+- verify Scout, Worker, and Judge agent availability or record an explicit truthful state;
 - print the exact command `/goal Follow docs/goals/<slug>/goal.md.`;
 - ask whether to start now, refine `goal.md`, or stop.
 
@@ -203,7 +240,7 @@ docs/goals/<slug>/
   notes/
 ```
 
-The goal root may contain only `goal.md`, `state.yaml`, and `notes/`.
+The goal root may contain only `goal.md`, `state.yaml`, `notes/`, and generated `.goalbuddy-board/` files when the local visual board is enabled.
 
 Most results live inline as task receipts in `state.yaml`. Only create `notes/<task-id>-<slug>.md` when Scout, Judge, or PM output is too large to fit on the task card.
 
@@ -409,6 +446,25 @@ Blocked tasks do not necessarily block the goal. The PM should keep doing safe l
 
 Avoid setting `goal.status: blocked` for missing input, credentials, production access, destructive-operation permission, or policy decisions. Block the specific task instead, record the missing requirement, and continue with every safe local workaround or adjacent slice.
 
+## Operator Escalation
+
+When Scout, Judge, Worker, or PM discovers a problem, improvement opportunity, product suggestion, follow-up repair, or tool limitation that should not be fixed inside the current active task, do not let it disappear in chat.
+
+The PM may create a board task to prepare a repo-native follow-up. If the user has already approved publishing and the repo/auth state supports it, the PM may create an issue or PR directly and record the link in the receipt. Otherwise, ask the operator one concise question before creating the external artifact:
+
+```markdown
+I found [problem or suggestion].
+
+Should I:
+1. Create an issue in this repo for it? (Recommended) - [why]
+2. Prepare a PR for the fix/suggestion - [when this is better]
+3. Keep it only in the GoalBuddy board for now - [tradeoff]
+```
+
+Use an issue for follow-up work, unclear scope, missing approval, or suggestions that need discussion. Use a PR when the fix is already implemented or safely implementable within the current approved scope. If neither is appropriate, propose a different path and record the decision in `state.yaml`.
+
+External issues and PRs are supporting artifacts, not board truth. `state.yaml` remains authoritative, and every issue/PR creation or decision must be reflected in a PM, Worker, or Judge receipt.
+
 ## Continuation Rule
 
 After a task completes, immediately write its receipt and select the next active task unless:
@@ -435,7 +491,18 @@ If the checker and your judgment disagree, choose the more conservative state.
 
 ## Agents
 
-Scout, Worker, and Judge are default-installed roles.
+Scout, Worker, and Judge templates are bundled with GoalBuddy. They may also be installed as user or project agent configs, but a board must not claim `installed` unless the preparer verified the matching agent files.
+
+Use these `state.yaml` values:
+
+| State | Meaning | Next action |
+|---|---|---|
+| `installed` | Matching Scout/Worker/Judge agent configs were found in the expected user or project agent location. | Continue. |
+| `bundled_not_installed` | The bundled `goal_*.toml` template exists with the skill, but no matching installed agent config was verified. | `/goal` can proceed through PM fallback. If dedicated agents are required before `/goal`, run `npx goalbuddy agents`. |
+| `missing` | Neither an installed config nor the bundled template was verified. | `/goal` can proceed through PM fallback. If dedicated agents are required before `/goal`, run `npx goalbuddy install`. |
+| `unknown` | Agent availability could not be checked. | `/goal` can proceed through PM fallback. To check before `/goal`, run `npx goalbuddy doctor`. |
+
+Non-`installed` states are warnings, not false failures, because the main `/goal` PM can perform Scout/Judge/Worker-shaped tasks directly when dedicated agents are unavailable.
 
 | Agent | Thinking level | Write access | Use for |
 |---|---:|---:|---|

package/goalbuddy/extend/github-projects/README.md

@@ -0,0 +1,105 @@
+# GitHub Projects
+
+Mirror a GoalBuddy `state.yaml` board into GitHub Projects without making GitHub the source of truth.
+
+This extension ports the GitHub Projects work from PR #1 into the catalog-based extension system. It keeps the package core dependency-free and optional, while giving teams a practical way to publish a GoalBuddy board into a familiar project surface.
+
+## Use When
+
+- A long-running GoalBuddy board needs stakeholder visibility in GitHub Projects.
+- A team wants one-way sync from `state.yaml` into ProjectV2 draft issues.
+- The PM needs a dry-run plan before using GitHub credentials.
+- Existing GoalBuddy receipts, verification commands, allowed files, owners, and dependencies should be visible in a board layout.
+
+## What It Creates
+
+The live sync ensures a GitHub Project has:
+
+- Draft issues keyed by `Task ID`, so reruns update existing cards instead of duplicating them.
+- Status mapping: `queued -> Todo`, `active -> In Progress`, `blocked -> Blocked`, `done -> Done`.
+- Single-select fields for `Status`, `Priority`, `Work Type`, and `Agent Lane`.
+- Text fields for `Task ID`, `Owner`, `Goal Role`, `Agent Responsible`, `Credential Gate`, `Parent ID`, `Depends On`, `Receipt Summary`, `Verify`, `Allowed Files`, and `Goal Updated`.
+- A `Goal Board` board-layout view for PM flow.
+
+The extension must use the bundled sync script for live writes. Do not use Computer Use, browser automation, or the GitHub web UI to create or repair the board view. Do not replace the script with `gh project` commands; `gh project` does not expose the complete ProjectV2 view creation path this extension needs. The script uses GitHub GraphQL for projects, fields, items, and draft issues, plus the GitHub REST Project views endpoint for the `Goal Board` view.
+
+The sync only creates or reuses `Goal Board`. It does not create a default Table view, an `Agent Workboard`, or extra role-specific views. GitHub may still show views that already existed on the Project.
+
+The extension does not promise custom board grouping or sort order. GitHub's public Project views REST API currently accepts `name`, `layout`, `filter`, and `visible_fields` when creating a view, and GraphQL exposes grouping/sort fields for reading but not a public mutation for saving them. Because that display state cannot be written reliably through the public API, the sync only creates supported fields, cards, and the single `Goal Board` view.
+
+## Inputs
+
+- `docs/goals/<slug>/state.yaml`
+- Optional `GITHUB_PROJECT_ID`
+- Optional `GITHUB_PROJECT_OWNER` and `GITHUB_PROJECT_NUMBER`
+- `GITHUB_TOKEN` or `GH_TOKEN` for live sync
+
+## Dry Run
+
+Dry-run mode does not call GitHub:
+
+```bash
+node extend/github-projects/scripts/sync-github-project.mjs \
+  --state docs/goals/<slug>/state.yaml \
+  --dry-run
+```
+
+For structured output:
+
+```bash
+node extend/github-projects/scripts/sync-github-project.mjs \
+  --state docs/goals/<slug>/state.yaml \
+  --dry-run \
+  --json
+```
+
+## Live Sync
+
+Always run the bundled script for live sync. It creates or reuses the `Goal Board` view as part of the same run that syncs fields and draft issues.
+
+Use a ProjectV2 node ID:
+
+```bash
+GITHUB_TOKEN=... node extend/github-projects/scripts/sync-github-project.mjs \
+  --state docs/goals/<slug>/state.yaml \
+  --project-id <project-node-id>
+```
+
+Or use an owner and project number:
+
+```bash
+GITHUB_TOKEN=... node extend/github-projects/scripts/sync-github-project.mjs \
+  --state docs/goals/<slug>/state.yaml \
+  --owner <user-or-org> \
+  --project-number <number>
+```
+
+Environment alternatives:
+
+- `GITHUB_PROJECT_ID`
+- `GITHUB_PROJECT_OWNER`
+- `GITHUB_PROJECT_NUMBER`
+- `GITHUB_TOKEN` or `GH_TOKEN`
+
+## Verification
+
+```bash
+node --test extend/github-projects/test/*.test.mjs
+node extend/github-projects/scripts/sync-github-project.mjs \
+  --state extend/github-projects/examples/goal-board-sync/state.yaml \
+  --dry-run
+node extend/github-projects/scripts/sync-github-project.mjs \
+  --state extend/github-projects/examples/goal-board-sync/state.yaml \
+  --dry-run \
+  --json
+```
+
+## Boundaries
+
+- `state.yaml` remains authoritative.
+- The sync is one-way from GoalBuddy to GitHub Projects.
+- Missing GitHub credentials block only live sync, not local dry-run validation.
+- Live sync creates or updates GitHub Project draft issues, fields, and the `Goal Board` view through the bundled script.
+- Agents must not fall back to Computer Use, browser automation, or the GitHub web UI for Project setup.
+- Agents must not claim ProjectV2 board views are UI-only; GitHub's REST Project views API supports creating board-layout views.
+- Native GitHub issue hierarchy and dependencies are represented as fields because ProjectV2 draft issues do not provide full issue relationship semantics.

package/goalbuddy/extend/github-projects/examples/goal-board-sync/state.yaml

@@ -0,0 +1,63 @@
+version: 2
+
+goal:
+  title: "Goal board sync MVP"
+  slug: "goal-board-sync-mvp"
+  kind: specific
+  tranche: "Mirror a GoalBuddy board into an external Kanban surface."
+  status: active
+
+rules:
+  pm_owns_state: true
+  one_active_task: true
+  max_write_workers: 1
+  no_implementation_without_worker_or_pm_task: true
+  no_completion_without_judge_or_pm_audit: true
+
+active_task: T002
+
+tasks:
+  - id: T001
+    type: scout
+    assignee: Scout
+    status: done
+    priority: P3
+    objective: "Map external board API requirements."
+    inputs:
+      - "Board API docs"
+    constraints:
+      - "Read-only."
+    expected_output:
+      - "Required scopes"
+      - "Field mapping"
+    receipt:
+      result: done
+      summary: "The board sync can read GoalBuddy state.yaml and mirror tasks into an external board."
+  - id: T002
+    type: worker
+    assignee: Worker
+    status: active
+    priority: P1
+    objective: "Implement one-way external board sync."
+    parent: T001
+    depends_on:
+      - T001
+    allowed_files:
+      - "extend/github-projects/scripts/**"
+      - "README.md"
+    verify:
+      - "node --test extend/github-projects/test/*.test.mjs"
+      - "node extend/github-projects/scripts/sync-github-project.mjs --state extend/github-projects/examples/goal-board-sync/state.yaml --dry-run"
+    stop_if:
+      - "Board API credentials are unavailable."
+    receipt: null
+  - id: T003
+    type: judge
+    assignee: Judge
+    status: queued
+    priority: P2
+    objective: "Audit whether the board sync MVP is ready to document."
+    parent: T002
+    depends_on:
+      - T002
+    receipt: null

package/goalbuddy/extend/github-projects/extension.yaml

@@ -0,0 +1,43 @@
+id: github-projects
+name: GitHub Projects
+kind: integration
+version: 0.1.1
+source_of_truth: local
+description: Mirror GoalBuddy state.yaml tasks into GitHub Projects with dry-run planning, ProjectV2 fields, draft issue upserts, and one Goal Board view.
+local_use_prompt: Run the bundled GitHub Projects sync script for docs/goals/<slug>/state.yaml. Use --dry-run first unless the user has approved live GitHub writes, then run the same script with GITHUB_TOKEN or GH_TOKEN and --project-id or --owner plus --project-number. Do not use Computer Use, browser automation, the GitHub web UI, or gh project as a fallback.
+use_when:
+  - A long-running GoalBuddy board needs stakeholder visibility in GitHub Projects.
+  - The team wants one-way sync from state.yaml into ProjectV2 draft issues.
+  - The PM needs a safe dry-run plan before using GitHub credentials.
+  - GoalBuddy receipts, verification commands, allowed files, owners, role/agent fields, credential gates, and dependencies should appear in a GitHub board.
+activation: publish_handoff
+outputs:
+  - GitHub Projects dry-run plan
+  - GitHub ProjectV2 draft issue sync
+  - Goal Board ProjectV2 view
+requires_approval: true
+safe_by_default: false
+reads:
+  - docs/goals/<slug>/state.yaml
+  - GITHUB_PROJECT_ID
+  - GITHUB_PROJECT_OWNER
+  - GITHUB_PROJECT_NUMBER
+writes:
+  - GitHub ProjectV2 draft issues
+  - GitHub ProjectV2 fields
+  - GitHub ProjectV2 Goal Board view
+side_effects:
+  - Live sync creates or updates GitHub Project draft issues, fields, and views.
+agent_instructions:
+  - Use the bundled sync script for all live GitHub Projects writes.
+  - Do not use Computer Use, browser automation, or the GitHub web UI to create or repair Project views.
+  - Do not replace the bundled script with gh project commands; the script uses GraphQL plus the REST Project views endpoint.
+  - Do not claim ProjectV2 board views are UI-only; the GitHub REST Project views API supports creating board-layout views.
+auth:
+  env:
+    - GITHUB_TOKEN
+supports:
+  dry_run: true
+  live_github_projects: true
+  credentials_required: true
+  one_way_sync: true