Skip to content

GitDocket v0.6.0

Choose a tag to compare

View all tags
@gbailey4 gbailey4 released this 25 Sep 03:11
· 19 commits to main since this release
v0.6.0
02f207d

GitDocket 0.6.0

GitDocket 0.6.0 adds wiki authoring, accepted Decision records, Mermaid diagrams and a combined view of task progress across linked Git worktrees. It also makes parallel tracked work explicit and moves Linux release qualification into local Docker.

Write and reorganize project knowledge

  • Create Reference, Spec and Playbook pages with Wiki → New page in the browser, the docket-wiki agent workflow, or the new CLI/MCP document operations. Browser drafts retain their content through navigation, reload and save errors in the same tab; preview and collision checks help you review a page before saving.
  • Read and revise complete documents with version checks. A stale edit or an occupied creation path fails without overwriting newer content. Wiki authoring does not start tracked work or select project guidance.
  • Plan and apply wiki moves with docket document move-plan and move-apply. Docket repairs supported Markdown links and fragments, preserves relative outbound targets and refreshes the index. Changed source invalidates a plan; interrupted writes retain a recovery journal for move-recover. Unsupported or external references are reported for explicit reconciliation.
  • Record an accepted choice with docket decision create or MCP decision_create. Decisions have Context, Decision and Consequences sections and a configurable ids.decision_prefix (default DEC). ID allocation is coordinated across linked worktrees. docket task create --type now accepts Task or Epic; use the dedicated Decision command for decisions.

See work across branches

docket task progress [ID] --json, MCP task_progress, and browser task, board and epic views expose saved task changes from accessible linked worktrees and committed versions in locally available refs. Observations identify their source, incomplete coverage, conflicts and integration evidence. Tasks found only elsewhere remain read-only in the current checkout.

Recorded status and observed progress stay distinct. A branch can report “done” while its changes await integration; matching status after a squash or cherry-pick alone does not prove integration. Dependencies still use the current checkout's recorded state. Reads do not fetch, merge or copy task files, and pickup markers do not claim an agent is running.

Starting a different task in an occupied checkout now returns active-task-conflict, naming both tasks and suggesting an explicit hand-off or a separate linked worktree. Agent guidance checks the branch, starting commit and task availability before isolation. Worktree creation requires explicit authorization unless the request, session or project guidance already grants it.

Projects can opt into reopening closed Tasks or Epics with workflow.reopen_closed: [Task, Epic]. Reopening returns closed work to the queue, requires a reason and preserves the earlier disposition in history. Existing projects retain terminal closed states unless configured; completed done work stays terminal.

Render diagrams locally

Fenced mermaid blocks render as diagrams in Markdown pages and editor previews. Diagram code remains editable Markdown. Mermaid loads only when needed from bundled local assets, including in standalone installations without external network access. Strict rendering, contained errors and source fallback keep a failing diagram from breaking adjacent content.

Release and installation reliability

The release operator now has commands for isolated workspaces, qualification, candidate review packets, bounded waits, owner login and promotion. Receipts retain source identities, checksums, completed steps and resume instructions. Publication verifies the coordinated package set under staged before owner promotion to latest, preserving accepted writes during registry propagation delays.

Linux ARM64 and x64 release qualification runs in local Ubuntu 24.04 Docker containers, including npm/Homebrew lifecycle checks and historical, customized and stale project upgrades. macOS checks remain local, with Intel execution through Rosetta. Receipts identify Docker emulation and Rosetta assistance. Automatic standalone builds on pushes and pull requests are removed; ordinary Linux CI and trusted publication remain on GitHub Actions.

Install and upgrade

brew install gitdocket/tap/gitdocket
docket --version
docket-mcp --version

Existing Homebrew users can run brew update followed by brew upgrade gitdocket. The project formula supplies standalone CLI/MCP executables for macOS 15+ and Homebrew-compatible glibc Linux on ARM64 and x64. It requires Git, with no separate Bun, Node or npm installation. Windows and musl/Alpine are not qualified.

Node 22+ users can instead run npm install -g --include=optional @gitdocket/cli@0.6.0 @gitdocket/mcp@0.6.0. All eight coordinated packages use 0.6.0; core/web libraries and source development remain Bun-based.

After updating executables, review docket upgrade --dry-run --json in each project, then apply docket upgrade and reconcile reported conflicts or retained differences. Package installation does not rewrite project instructions. Published workflow merge bases remain preserved. Restart an existing agent session if its skill inventory predates the new wiki workflow.

Verification

Assets 15
Loading