goalbuddy 0.2.21 → 0.2.22

package/plugins/goalbuddy/README.md

@@ -26,11 +26,7 @@ Install and enable GoalBuddy:
 npx goalbuddy
 ```
 
-Restart Codex, then use `$goal-prep`. Optional extensions can be installed with:
-
-```bash
-npx goalbuddy extend install --all
-```
+Restart Codex, then use `$goal-prep`. The plugin bundles the local live board and GitHub Projects visual board backends so Goal Prep can offer a board immediately.
 
 Or install the npm package globally:
 

package/plugins/goalbuddy/skills/goalbuddy/SKILL.md

@@ -24,15 +24,16 @@ 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.
 
@@ -72,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.
@@ -117,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.
 
@@ -155,9 +173,10 @@ Do:
 - 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.
 
@@ -221,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.
 
@@ -472,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/plugins/goalbuddy/skills/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/plugins/goalbuddy/skills/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/plugins/goalbuddy/skills/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