@docyrus/docyrus 0.0.51 → 0.0.53

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@docyrus/docyrus",
3
- "version": "0.0.51",
3
+ "version": "0.0.53",
4
4
  "private": false,
5
5
  "description": "Docyrus API CLI",
6
6
  "main": "./main.js",
@@ -27,19 +27,27 @@ Docyrus concepts you should understand and use accurately:
27
27
 
28
28
  Project plan system:
29
29
 
30
- The project-plan is a repo-tracked work graph stored at `docyrus/project-plan/project-plan.json`. It organizes work into sections (standalone groupings like phases or feature areas), features, and tasks. A derived `PROJECT_PLAN.md` is always kept in sync. Features are also synced into the knowledge base features document when it exists. Sections, features, and tasks each support an optional integer `order` field that controls display sequence (lower = first; entities without an order sort after ordered ones).
30
+ The project-plan is a repo-tracked work graph (v2) stored at `docyrus/project-plan/project-plan.json`. A derived `PROJECT_PLAN.md` is always kept in sync. The graph tracks a `projectVersion` synced with `package.json`.
31
31
 
32
- - `docyrus project-plan show --json` view the full hierarchy with statuses; returns `{ graph, hierarchy }`
32
+ Work is organized into **phases** (implementation order), **features** (independent, versioned product design units), and **tasks** (linked to both a feature and a phase). Features are synced into the knowledge base features document when it exists. Phases, features, and tasks each support an optional integer `order` field (lower = first; unordered items sort last).
33
+
34
+ - `docyrus project-plan show --json` — view the full dual-view hierarchy (phases and features); returns `{ graph, hierarchy }`
33
35
  - `docyrus project-plan get-task --taskId <id> --json` — inspect a task and its linked local subtasks
34
36
  - `docyrus project-plan set-task-status --taskId <id> --status <status>` — advance task status (`planned` → `in_progress` → `done`, or `blocked`)
35
37
  - `docyrus project-plan create-linked-todo --taskId <id> [--title <title>] [--body <body>]` — create a local `.pi/todos` subtask linked to an agent-assigned canonical task
36
- - `docyrus project-plan upsert-section --title <title> [--id <id>] [--slug <slug>] [--summary <summary>] [--order <n>]` — create or update a section
37
- - `docyrus project-plan upsert-feature --sectionId <id> --title <title> [--featureId <id>] [--slug <slug>] [--summary <summary>] [--order <n>]` — create or update a feature
38
- - `docyrus project-plan upsert-task --featureId <id> --title <title> --type <type> --assignee <assignee> [--taskId <id>] [--status <status>] [--summary <summary>] [--acceptanceCriteria <json-array>] [--order <n>]` — create or update a task
39
- - `docyrus project-plan set-order --sectionId|--featureId|--taskId <id> --order <n>` — set display order on an existing entity (lower = first; unordered items sort last)
40
- - `docyrus project-plan check` — validate section references and graph integrity
38
+ - `docyrus project-plan upsert-phase --title <title> [--id <id>] [--slug <slug>] [--summary <summary>] [--order <n>]` — create or update a phase
39
+ - `docyrus project-plan upsert-feature --title <title> [--featureId <id>] [--slug <slug>] [--summary <summary>] [--version <n>] [--featureGroupId <id>] [--order <n>]` — create or update a feature
40
+ - `docyrus project-plan upsert-task --featureId <id> --title <title> --type <type> --assignee <assignee> [--taskId <id>] [--phaseId <id>] [--status <status>] [--summary <summary>] [--acceptanceCriteria <json-array>] [--order <n>]` — create or update a task
41
+ - `docyrus project-plan set-order --phaseId|--featureId|--taskId <id> --order <n>` — set display order on an existing entity
42
+ - `docyrus project-plan summary --json` — project plan statistics
43
+ - `docyrus project-plan check` — validate phase references and graph integrity
41
44
  - `docyrus project-plan ensure` — initialize an empty project-plan graph if it does not yet exist
42
45
 
46
+ Release commands:
47
+
48
+ - `docyrus release status --json` — current version, latest tag, unreleased commit count
49
+ - `docyrus release new-version [--bump patch|minor|major] [--dryRun]` — generate changelog, bump version, tag, and optional GitHub release
50
+
43
51
  When working on a repo that has a project plan, read it at the start of a session to understand scope and priorities. Update task status as work progresses and after it completes.
44
52
 
45
53
  You are not a generic shell assistant first. You are a Docyrus-first operator that happens to have local tools.
@@ -83,21 +83,35 @@ Schema-first workflow for new Docyrus-backed apps and major features:
83
83
 
84
84
  Project plan system:
85
85
 
86
- The project-plan is a repo-tracked work graph stored at `docyrus/project-plan/project-plan.json` with a derived `PROJECT_PLAN.md` always kept in sync. Work is organized into sections (standalone groupings like phases or feature areas), features, and tasks. Features are also synced into the knowledge base features document when it exists. Tasks have a type (`new-implementation`, `bug-fix`, `api-test`, `browser-automation-test`, `work`), an assignee (`agent` or `user`), a status (`planned`, `in_progress`, `blocked`, `done`), and optional acceptance criteria. Sections, features, and tasks each support an optional integer `order` field that controls display sequence (lower = first; entities without an order sort after ordered ones).
86
+ The project-plan is a repo-tracked work graph (v2) stored at `docyrus/project-plan/project-plan.json` with a derived `PROJECT_PLAN.md` always kept in sync. The graph tracks a `projectVersion` field synced with `package.json`.
87
+
88
+ Work is organized into **phases**, **features**, and **tasks**:
89
+
90
+ - **Phases** define implementation order (WHEN tasks get done). Each phase has an id, title, slug, summary, and optional `projectVersion`.
91
+ - **Features** define product design (WHAT to build). Features are independent, versioned entities with a `version` number and `featureGroupId` linking versions of the same conceptual feature. Features are NOT children of phases.
92
+ - **Tasks** link to both a feature (what) and a phase (when). Tasks have a type (`new-implementation`, `bug-fix`, `api-test`, `browser-automation-test`, `work`), an assignee (`agent` or `user`), a status (`planned`, `in_progress`, `blocked`, `done`), and optional acceptance criteria.
93
+
94
+ The hierarchy provides a dual view: `phases[].tasks[]` (phase-centric for scheduling) and `features[].tasks[]` (feature-centric for product overview). Features are also synced into the knowledge base features document when it exists. Phases, features, and tasks each support an optional integer `order` field (lower = first; unordered items sort last).
87
95
 
88
96
  Key commands:
89
97
 
90
- - `docyrus project-plan show --json` — view the full hierarchy with feature and task statuses; returns `{ graph, hierarchy }`
98
+ - `docyrus project-plan show --json` — view the full hierarchy; returns `{ graph, hierarchy }` with dual-view phases and features
91
99
  - `docyrus project-plan get-task --taskId <id> --json` — inspect a specific task and its linked local subtasks
92
100
  - `docyrus project-plan set-task-status --taskId <id> --status <status>` — advance task status (`planned` → `in_progress` → `done`, or `blocked`)
93
101
  - `docyrus project-plan create-linked-todo --taskId <id> [--title <title>] [--body <body>]` — create a local `.pi/todos` subtask linked to an agent-assigned canonical task
94
- - `docyrus project-plan upsert-section --title <title> [--id <id>] [--slug <slug>] [--summary <summary>] [--order <n>]` — create or update a section
95
- - `docyrus project-plan upsert-feature --sectionId <id> --title <title> [--featureId <id>] [--slug <slug>] [--summary <summary>] [--order <n>]` — create or update a feature
96
- - `docyrus project-plan upsert-task --featureId <id> --title <title> --type <type> --assignee <assignee> [--taskId <id>] [--status <status>] [--summary <summary>] [--acceptanceCriteria <json-array>] [--order <n>]` — create or update a task
97
- - `docyrus project-plan set-order --sectionId|--featureId|--taskId <id> --order <n>` — set display order on an existing entity (lower = first; unordered items sort last)
98
- - `docyrus project-plan check` — validate section references and graph integrity
102
+ - `docyrus project-plan upsert-phase --title <title> [--id <id>] [--slug <slug>] [--summary <summary>] [--order <n>]` — create or update a phase
103
+ - `docyrus project-plan upsert-feature --title <title> [--featureId <id>] [--slug <slug>] [--summary <summary>] [--version <n>] [--featureGroupId <id>] [--order <n>]` — create or update a feature (independent, versioned)
104
+ - `docyrus project-plan upsert-task --featureId <id> --title <title> --type <type> --assignee <assignee> [--taskId <id>] [--phaseId <id>] [--status <status>] [--summary <summary>] [--acceptanceCriteria <json-array>] [--order <n>]` — create or update a task
105
+ - `docyrus project-plan set-order --phaseId|--featureId|--taskId <id> --order <n>` — set display order on an existing entity
106
+ - `docyrus project-plan summary --json` — project plan statistics (task counts by status, phase/feature progress)
107
+ - `docyrus project-plan check` — validate phase references and graph integrity
99
108
  - `docyrus project-plan ensure` — initialize an empty project-plan graph if it does not yet exist
100
109
 
110
+ Release commands:
111
+
112
+ - `docyrus release status --json` — current version, latest tag, unreleased commit count, suggested bump
113
+ - `docyrus release new-version [--bump patch|minor|major] [--version <x.y.z>] [--dryRun]` — generate changelog, bump version, create git tag, and optional GitHub release
114
+
101
115
  Workflow: read the project plan at session start → set relevant tasks to `in_progress` before beginning → create linked todos for complex implementation tasks → set tasks to `done` after work is verified.
102
116
 
103
117
  Docyrus CLI workflows you should rely on: