Normalize file command parameters - #64
Merged
Merged
Conversation
Signed-off-by: Nic Jackson <jackson.nic@gmail.com>
These are the user's changes from before the plan workflow for 000058_plan-task-graph started. Spektacular committed them separately at the user's request so they are not mixed with the agent's work. Signed-off-by: Nic Jackson <jackson.nic@gmail.com>
…implement Plan for spec 000058_plan-task-graph (issue #50), built on the plan-task-graph design. Four milestones, twelve phases: - A shared plan task reader and validator; plan.md writes refuse invalid task structure; `plan task-id` with a pluggable provider (uuid default); milestone commits moved onto the reader. - `plan export` (pretty/json) and per-task progress in `plan status`. - Single-task `implement new` with up-front refusals, last-open-task wrap-up routing and task-scoped implement instructions. - Plan workflow authors tasks (phases step renamed to tasks, human-task criteria, walkthrough names human tasks), glossary and harbor oracles, and public docs for the task format, export and single-task implement. Signed-off-by: Nic Jackson <jackson.nic@gmail.com>
The plan documents are committed to the plan store; the per-section working files are no longer needed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Nic Jackson <jackson.nic@gmail.com>
…ask structure - internal/plantask: one reader for a plan's Milestones & Tasks section (ids, repo, dependencies, executor, completion, criteria counts) with a validator for the design's structural rules; legacy Phase plans parse as their own format. - plan file write refuses a task-format plan.md that breaks a rule (plan_task_invalid, naming the task) before anything is stored; phase plans and other plan documents save as before. - plan task-id issues ids from a pluggable provider (plan.task_id.provider, default uuid); unknown providers fail only the id request. - Milestone auto-commits and implement status's unchecked_phases count now go through the reader, for task and phase plans alike. Signed-off-by: Nic Jackson <jackson.nic@gmail.com>
…aph and per-task progress
- plan export <name> [--format pretty|json] parses plan.md at call time
and prints the design's grouped text view by default or the JSON task
graph (kind, name, document_status, tasks with id, title, milestone,
repo {name, location}, depends_on, execution {type, reason},
completed). repo.location comes only from a declared git source.
Unsupported formats, missing plans and plans without task structure
are refused with structured JSON errors.
- Export and plan status share one document-status computation,
including strict staleness, so they always agree.
- plan status <name> reports progress {tasks_completed, tasks_total} and
per-task completion plus acceptance criteria met/total for task plans;
existing fields are unchanged.
Signed-off-by: Nic Jackson <jackson.nic@gmail.com>
… plan on its own - implement new accepts a task id and refuses, before any state is written, a task that cannot start: plan_structure_invalid, task_not_found, task_completed, task_dependencies_incomplete (listing the open dependencies) and task_requires_human (with its reason). implement status and the resume report carry the task. - A single-task run goes straight from update_changelog to finished while other tasks remain open; the run that completes the last open task does the test plan, feature changelog and spec reconciliation. The new edge is a completion commit point, and completion commits are now matched on the step's rendered exit so whole-plan runs are unchanged; in full mode they also record any milestone the task closed. - Implement step templates share a current-task partial: a task run names and works on only the selected task, while read_plan still reads the whole plan, context, research and designs. Templates, skills and partials move to task wording, with a fallback for phase plans. Signed-off-by: Nic Jackson <jackson.nic@gmail.com>
…asks, feature documented - The plan workflow's phases step is now a tasks step: ids from plan task-id, exactly one repo, explicit Depends on, and Execution decided against the four human-task criteria, with mixed work split. Scaffolds, assemble, verification and the walkthrough (which names every human task before sign-off) move to the task format; the spek-plan skill and the managed store-access wording follow. - Glossary: the phase term is replaced by task. - Harbor plan-workflow oracles and reference solution move to the tasks step and format and check every task's lines and a clean export; both plan-workflow (95/95) and implement-workflow (14/14, legacy plan) pass. - Docs: new Plan tasks page (format, human-task criteria, task ids, plan export and every field, progress, single-task implement), linked from the nav; How it works and Configuration updated. Signed-off-by: Nic Jackson <jackson.nic@gmail.com>
… spec reconciliation - Test plan: post-release observation procedures for the four success metrics, plus manual checks for splitting mixed work on the reference scenario and asking an agent to implement one task. - Project changelog record plus per-repo records for spektacular and docs. - Spec reconciled: every requirement delivered; three agent-behaviour acceptance criteria stay open pending the manual checks. Signed-off-by: Nic Jackson <jackson.nic@gmail.com>
Signed-off-by: Nic Jackson <jackson.nic@gmail.com>
Signed-off-by: Nic Jackson <jackson.nic@gmail.com>
…rtifact Specify normalised artifact addressing from issue #46. A feature's bare workflow name addresses its spec and changelog record; a plan is addressed by feature plus document name. Names never carry a file extension, list output round-trips into read, and an extension or a plan read without a document is an actionable refusal. Reported locations become relative to the declaring config across spec, plan and changelog (with and without --repo), and plan/implement status report the plan by name, document and relative path. Hard break with no deprecation window; shipped skills, step templates, docs and the documentation site move with it, plus a migration note. Design addressing, an implement file alias, and knowledge commands are out of scope. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Nic Jackson <jackson.nic@gmail.com>
…rtifact Plan for making a feature's bare name the address for its spec, plan documents and changelog record, in 11 tasks over three milestones: - Milestone 1: new internal/artifact address package; spec/plan/changelog file commands take bare names (plan: <feature> <document>); old spellings refused with unexpected_extension / document_required and a corrected next_action; shipped skills, step templates and harbor suites moved to the new form, guarded by tests; manual end-to-end run replaces harbor runs. - Milestone 2: list and status locations relative to the declaring config; plan_document added; absolute path template variables removed so instructions name documents by address and CLI read, never a file path. - Milestone 3: README, CHANGELOG migration note, and a new docs-site document command reference page. Also updates knowledge entries architecture/working-with-files-from-steps.md and architecture/workflow-steps.md: agent-facing output never contains a path to a store document, since the store may not be on disk. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Nic Jackson <jackson.nic@gmail.com>
…cations and address-only step output Implements the addressing change and relative locations for spec, plan and changelog documents: - New internal/artifact package owns the address grammar (bare feature name; plan feature plus document), the file layout mapping and the unexpected_extension and document_required codes. - spec/plan/changelog file verbs parse through it: old spellings are refused with a next_action restating the same command correctly spelled, lists print bare names, and not_found points at the list. - Workflow layout helpers and the walkthrough revision hint go through the address; skills, step templates, the partial and harbor suites use the new spellings, guarded by template and rendered-corpus tests. Installed .claude/.bob skill copies regenerated (includes pre-existing drift such as the missing .bob spek-design copy). - List and set-document-status paths, plan/implement status plan_path, and new/goto spec_path/plan_path are now relative to the declaring config folder, with plan_document added. Step instructions no longer render host paths to store documents. - README documents the addressing rules; the docs site (docs repo) gains a Documents reference page, configuration notes and a status sample. The manual end-to-end task (Milestone 1) is left for a person to run. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Nic Jackson <jackson.nic@gmail.com>
…g, locations and migration Documents the new addressing in the CLI repo: the README gains an "Addressing specs, plans and changelog records" section covering bare names, the <feature> <document> plan form, list name and path, the status plan fields and the unexpected_extension and document_required refusals, and says reported locations share the config.yaml base. CHANGELOG.md gains the 000059 entry with a breaking-change note mapping every old spelling to its new form. The docs site page landed with the Milestone 2 commit. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Nic Jackson <jackson.nic@gmail.com>
…esses every document Closes Milestone 1 with the manual end-to-end check: the user drove the new spec, plan and changelog commands by hand and confirmed them, in place of running the harbor suites. The addressing change, template migration, harbor spellings and guards shipped in the Milestone 2 commit; this records the verification and the plan's changelog entry. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Nic Jackson <jackson.nic@gmail.com>
Wraps up the implement workflow for normalised artifact addressing: - Test plan written for the two post-release metrics (no reports of a listed name being refused, and no host paths or internal errors from the document commands). - Project-level changelog record plus derived records for the spektacular and docs repos, each opening with a user-facing summary and listing the deviations from the plan. - Spec reconciled: all 14 requirements and 12 acceptance criteria are satisfied by the shipped work and the user's manual end-to-end check. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Nic Jackson <jackson.nic@gmail.com>
|
PR needs rebase. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Signed-off-by: Nic Jackson <jackson.nic@gmail.com>
Collaborator
Author
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: nicholasjackson The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
13 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.