taskledger 0.1.0__tar.gz → 0.1.2__tar.gz

{taskledger-0.1.0 → taskledger-0.1.2}/API.md

@@ -11,6 +11,7 @@ This repository exposes a task-first public API. The supported modules are:
 - `taskledger.api.introductions`
 - `taskledger.api.locks`
 - `taskledger.api.handoff`
+- `taskledger.api.releases`
 - `taskledger.api.search`
 
 ## Import boundary
@@ -66,7 +67,9 @@ from taskledger.errors import (
 - `show_task`
 - `edit_task`
 - `cancel_task`
+- `uncancel_task`
 - `close_task`
+- `create_follow_up_task`
 - `add_requirement`
 - `remove_requirement`
 - `waive_requirement`
@@ -83,11 +86,13 @@ from taskledger.errors import (
 - `can_perform`
 - `reindex`
 - `repair_task_record`
+- `repair_orphaned_planning_run`
 
 ### `taskledger.api.plans`
 
 - `start_planning`
 - `propose_plan`
+- `plan_template`
 - `upsert_plan`
 - `regenerate_plan_from_answers`
 - `materialize_plan_todos`
@@ -103,6 +108,7 @@ from taskledger.errors import (
 ### `taskledger.api.questions`
 
 - `add_question`
+- `add_questions`
 - `list_questions`
 - `list_open_questions`
 - `answer_question`
@@ -114,6 +120,7 @@ from taskledger.errors import (
 
 - `start_implementation`
 - `restart_implementation`
+- `resume_implementation`
 - `log_implementation`
 - `add_implementation_deviation`
 - `add_implementation_artifact`
@@ -192,6 +199,13 @@ Focused handoffs store the generated Markdown context snapshot in the handoff
 record body and return compact metadata, including `context_hash` and
 `context_path`.
 
+### `taskledger.api.releases`
+
+- `build_changelog_context`
+- `list_release_records`
+- `show_release`
+- `tag_release`
+
 ### `taskledger.api.search`
 
 - `search_workspace`
@@ -213,6 +227,7 @@ The public task-first CLI surface is organized around these command groups:
 - `file`
 - `link`
 - `require`
+- `release`
 - `lock`
 - `context`
 - `handoff`
@@ -243,12 +258,23 @@ structured `error` object on failure.
 Workflow additions:
 
 - `task create` creates a task. Use `task activate TASK_REF` to make it active.
+- `task follow-up PARENT_REF TITLE` creates a new draft child task linked to a
+  completed parent. Use it for small post-completion deltas instead of
+  reopening the done task.
+- `plan template` and `question add-many` support faster plan drafting and batch
+  planning setup.
 - `plan draft`, `plan upsert --from-answers`, and
   `plan materialize-todos` support the question-answer-regenerate loop.
 - `question status` reports required open questions and whether regeneration is
-  needed.
+  needed, including plan-template hints when answered questions require a plan update.
 - `implement restart --summary ...` starts a new implementation run from
   `failed_validation` while preserving the prior failed validation history.
+- `implement resume --reason ...` reacquires an implementation lock for an
+  existing running implementation run after a lock break or other orphaned-lock
+  recovery.
+- `task uncancel --reason ... [--to STAGE]` restores truly cancelled tasks to a
+  safe durable non-active stage; active work still resumes through the normal
+  stage-specific commands.
 - `todo done` records evidence with `--evidence`, `--artifact`, and `--change`.
 - `handoff create|list|show|claim|close|cancel` are available on the main
   task-first handoff command group.

taskledger-0.1.2/CHANGELOG.md

@@ -0,0 +1,63 @@
+# Changelog
+
+## v0.1.1 - 2026-04-29
+
+### Added
+
+- Added `task follow-up` to create linked post-completion child tasks, preserve closure metadata, and show parent and follow-up relationships in task and handoff views.
+- Added durable release records and a new `taskledger release` command group with `tag`, `list`, `show`, and `changelog`, including export/import support and public API coverage.
+- Added planning helpers with `question add-many`, `plan template`, richer regeneration hints in `next-action`, and recovery commands for orphaned implementation work with `implement resume`, `task uncancel`, and `can implement-resume`.
+
+### Changed
+
+- Hardened CLI startup so optional command-group import failures no longer block core commands, and launcher failures return structured diagnostics.
+
+### Fixed
+
+- Fixed recovery guidance for uncancelled tasks with orphaned implementation runs so `next-action` and `can implement` recommend `implement resume` instead of a fresh start.
+
+### Documentation
+
+- Documented release tagging, changelog generation, planning helpers, follow-up task workflow, and recovery semantics across README, RST docs, API docs, and the taskledger skill.
+
+### Quality
+
+- Expanded regression coverage for follow-up tasks, release workflow, CLI import resilience, planning helpers, and implementation recovery. Repo-wide pytest, ruff, and mypy passed.
+
+## v0.1.0 - 2026-04-29
+
+### Added
+
+- Added initial unit test coverage for `storage/common`, `storage/init`, `storage/repos`, `domain/policies`, and `services/doctor_v2`, raising overall coverage from 62% to 65%.
+- Added a second coverage pass for storage memories, items, contexts, validation, and dashboard services, raising overall coverage to 73%.
+- Added question status filtering plus `taskledger question answers` with markdown and JSON output.
+- Added `taskledger plan lint`, stricter executable-plan linting, and approval gating for lint failures.
+- Added focused worker contexts and durable handoff snapshots for implementer and reviewer workflows.
+- Added richer `next-action` output with next item, command hints, and progress details.
+- Added project-root config discovery and external storage roots via `taskledger.toml`.
+- Added the localhost-only read-only `taskledger serve` dashboard.
+- Added an explicit failed-validation recovery path with `taskledger implement restart`.
+- Added compact single-agent workflow guidance and richer `todo next` and `todo show` hints.
+
+### Changed
+
+- Hardened agent guardrails by requiring reasons for approval escape hatches, blocking empty-todo approvals by default, and adding durable `plan command` execution.
+- Finished agent-protocol hardening with stronger typed normalization, safer plan todo materialization, and automatic todo source inference from the active lock.
+- Removed redundant derived task, plan-version, and latest-run indexes so Markdown bundles remain canonical and JSON indexes remain rebuildable caches.
+- Completed the broader pre-release cleanup pass from `todo.md`, including public API export cleanup, stricter storage diagnostics, canonical module paths, normalized JSON command naming, and packaging cleanup.
+- Extended the serve dashboard with a dedicated read model, recent-event tail loading, route caching, and non-overlapping partial refreshes for better hot-path performance.
+- Redesigned the serve dashboard into a more human-focused layout with richer sidebar metadata, accessibility coverage, and updated docs.
+- Improved dashboard review ergonomics and refresh stability with pause and resume controls, diffed rerenders, preserved details state, and lazy raw-payload rendering.
+- Finished release-readiness cleanup by consolidating maintained docs under RST and keeping `skills/taskledger/SKILL.md` as the single canonical skill file.
+
+### Fixed
+
+- Fixed `taskledger view` so todo counts and item lists reflect persisted todos instead of always showing `0/0`.
+- Fixed orphan slug-directory creation under `.taskledger/tasks/` and added repair support for existing bad directories.
+- Fixed repo-wide pre-commit and mypy failures across more than twenty files.
+- Fixed serve response handling so client disconnects no longer produce `BrokenPipeError` tracebacks.
+- Fixed the serve dashboard todo-renderer JavaScript regression that broke refresh parsing.
+
+### Quality
+
+- Improved testing depth across storage, dashboard, lifecycle, and documentation surfaces to support release readiness and regression protection.

{taskledger-0.1.0/taskledger.egg-info → taskledger-0.1.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: taskledger
-Version: 0.1.0
+Version: 0.1.2
 Summary: Durable project-state storage and CLI for coding workflows
 Author: Taskledger Contributors
 Maintainer: Holger Nahrstaedt
@@ -40,6 +40,11 @@ Provides-Extra: rich
 Requires-Dist: rich; extra == "rich"
 Dynamic: license-file
 
+[![PyPI - Version](https://img.shields.io/pypi/v/taskledger)](https://pypi.org/project/taskledger/)
+![PyPI - Python Version](https://img.shields.io/pypi/pyversions/taskledger)
+![PyPI - Downloads](https://img.shields.io/pypi/dm/taskledger)
+[![codecov](https://codecov.io/gh/holgern/taskledger/graph/badge.svg?token=6usFHwM5Ul)](https://codecov.io/gh/holgern/taskledger)
+
 # taskledger
 
 `taskledger` is a task-first durable state layer for staged coding work. It keeps
@@ -74,7 +79,7 @@ The supported command surface is organized as:
 
 **Project lifecycle:**
 
-- `init`, `status`, `export`, `import`, `snapshot`
+- `init`, `status`, `export`, `import`, `snapshot`, `release`
 
 ## Install
 
@@ -106,9 +111,10 @@ plan from answers, approve it, implement todos with evidence, and validate it:
 taskledger task create "Rewrite V2" --slug rewrite-v2 --description "Migrate to the task-first design."
 taskledger task activate rewrite-v2 --reason "Start planning"
 taskledger plan start
-taskledger question add --text "Should exports include the new state?" --required-for-plan
-taskledger question answer-many --text "q-0001: Yes."
+taskledger question add-many --required-for-plan --text $'Should exports include the new state?\nShould snapshots include implementation artifacts?'
+taskledger question answer-many --text $'q-0001: Yes.\nq-0002: No.'
 taskledger question status
+taskledger plan template --from-answers --file ./plan.md
 taskledger plan upsert --from-answers --file ./plan.md
 taskledger plan lint --version 1
 taskledger plan accept --version 1 --note "Ready."
@@ -150,6 +156,22 @@ taskledger context --for implementation --format markdown
 taskledger implement restart --summary "Fix failed validation findings."
 ```
 
+## Release tagging and changelog context
+
+Use durable release tags to mark completed task boundaries and generate
+provider-neutral changelog source packs from finished tasks:
+
+```bash
+taskledger release tag 0.4.1 --at-task task-0030 --note "0.4.1 released"
+taskledger release changelog 0.4.2 --since 0.4.1 --until-task task-0035 --output /tmp/taskledger-0.4.2-changelog-source.md
+taskledger release show 0.4.1
+taskledger release list
+```
+
+`release changelog` does not call an LLM API. It renders compact Markdown or JSON
+from done tasks, implementation logs, code changes, and validation evidence so a
+separate coding harness can draft the final human changelog.
+
 `taskledger next-action` is the preferred fresh-context entrypoint. It stays
 read-only and points at the next concrete question, todo, criterion, or repair
 step.
@@ -254,6 +276,7 @@ records under the configured storage root:
 taskledger.toml
 .taskledger/
   intros/
+  releases/
   tasks/
   events/
   indexes/   # optional derived caches and registries
@@ -272,6 +295,7 @@ taskledger init --taskledger-dir /mnt/cloud/taskledger/project-a
 ```text
 /home/me/src/project-a/taskledger.toml
 /mnt/cloud/taskledger/project-a/storage.yaml
+/mnt/cloud/taskledger/project-a/releases/
 /mnt/cloud/taskledger/project-a/tasks/
 /mnt/cloud/taskledger/project-a/events/
 /mnt/cloud/taskledger/project-a/indexes/
@@ -395,13 +419,19 @@ taskledger snapshot ./artifacts
 
 ## Skill packaging
 
+Agent workflows work best when the `taskledger` skill is installed in the
+coding harness. The CLI has a task-first lifecycle with explicit planning,
+approval, implementation, validation, locks, and handoff gates; without the
+skill, an agent may not know the intended command sequence or gate semantics.
+
 The canonical skill file lives at:
 
 ```text
 skills/taskledger/SKILL.md
 ```
 
-No additional `skills/taskledger/examples/` directory is required.
+Keep this skill outside the Python package. No additional
+`skills/taskledger/examples/` directory is required.
 
 ## Development
 

{taskledger-0.1.0 → taskledger-0.1.2}/README.md

@@ -1,3 +1,8 @@
+[![PyPI - Version](https://img.shields.io/pypi/v/taskledger)](https://pypi.org/project/taskledger/)
+![PyPI - Python Version](https://img.shields.io/pypi/pyversions/taskledger)
+![PyPI - Downloads](https://img.shields.io/pypi/dm/taskledger)
+[![codecov](https://codecov.io/gh/holgern/taskledger/graph/badge.svg?token=6usFHwM5Ul)](https://codecov.io/gh/holgern/taskledger)
+
 # taskledger
 
 `taskledger` is a task-first durable state layer for staged coding work. It keeps
@@ -32,7 +37,7 @@ The supported command surface is organized as:
 
 **Project lifecycle:**
 
-- `init`, `status`, `export`, `import`, `snapshot`
+- `init`, `status`, `export`, `import`, `snapshot`, `release`
 
 ## Install
 
@@ -64,9 +69,10 @@ plan from answers, approve it, implement todos with evidence, and validate it:
 taskledger task create "Rewrite V2" --slug rewrite-v2 --description "Migrate to the task-first design."
 taskledger task activate rewrite-v2 --reason "Start planning"
 taskledger plan start
-taskledger question add --text "Should exports include the new state?" --required-for-plan
-taskledger question answer-many --text "q-0001: Yes."
+taskledger question add-many --required-for-plan --text $'Should exports include the new state?\nShould snapshots include implementation artifacts?'
+taskledger question answer-many --text $'q-0001: Yes.\nq-0002: No.'
 taskledger question status
+taskledger plan template --from-answers --file ./plan.md
 taskledger plan upsert --from-answers --file ./plan.md
 taskledger plan lint --version 1
 taskledger plan accept --version 1 --note "Ready."
@@ -108,6 +114,22 @@ taskledger context --for implementation --format markdown
 taskledger implement restart --summary "Fix failed validation findings."
 ```
 
+## Release tagging and changelog context
+
+Use durable release tags to mark completed task boundaries and generate
+provider-neutral changelog source packs from finished tasks:
+
+```bash
+taskledger release tag 0.4.1 --at-task task-0030 --note "0.4.1 released"
+taskledger release changelog 0.4.2 --since 0.4.1 --until-task task-0035 --output /tmp/taskledger-0.4.2-changelog-source.md
+taskledger release show 0.4.1
+taskledger release list
+```
+
+`release changelog` does not call an LLM API. It renders compact Markdown or JSON
+from done tasks, implementation logs, code changes, and validation evidence so a
+separate coding harness can draft the final human changelog.
+
 `taskledger next-action` is the preferred fresh-context entrypoint. It stays
 read-only and points at the next concrete question, todo, criterion, or repair
 step.
@@ -212,6 +234,7 @@ records under the configured storage root:
 taskledger.toml
 .taskledger/
   intros/
+  releases/
   tasks/
   events/
   indexes/   # optional derived caches and registries
@@ -230,6 +253,7 @@ taskledger init --taskledger-dir /mnt/cloud/taskledger/project-a
 ```text
 /home/me/src/project-a/taskledger.toml
 /mnt/cloud/taskledger/project-a/storage.yaml
+/mnt/cloud/taskledger/project-a/releases/
 /mnt/cloud/taskledger/project-a/tasks/
 /mnt/cloud/taskledger/project-a/events/
 /mnt/cloud/taskledger/project-a/indexes/
@@ -353,13 +377,19 @@ taskledger snapshot ./artifacts
 
 ## Skill packaging
 
+Agent workflows work best when the `taskledger` skill is installed in the
+coding harness. The CLI has a task-first lifecycle with explicit planning,
+approval, implementation, validation, locks, and handoff gates; without the
+skill, an agent may not know the intended command sequence or gate semantics.
+
 The canonical skill file lives at:
 
 ```text
 skills/taskledger/SKILL.md
 ```
 
-No additional `skills/taskledger/examples/` directory is required.
+Keep this skill outside the Python package. No additional
+`skills/taskledger/examples/` directory is required.
 
 ## Development
 

{taskledger-0.1.0 → taskledger-0.1.2}/docs/api.rst

@@ -14,6 +14,7 @@ Supported modules
 - ``taskledger.api.introductions``
 - ``taskledger.api.locks``
 - ``taskledger.api.handoff``
+- ``taskledger.api.releases``
 - ``taskledger.api.search``
 
 Import boundary
@@ -46,7 +47,9 @@ Task API
 - ``show_task``
 - ``edit_task``
 - ``cancel_task``
+- ``uncancel_task``
 - ``close_task``
+- ``create_follow_up_task``
 - ``add_requirement``
 - ``remove_requirement``
 - ``waive_requirement``
@@ -63,12 +66,14 @@ Task API
 - ``can_perform``
 - ``reindex``
 - ``repair_task_record``
+- ``repair_orphaned_planning_run``
 
 Plan API
 --------
 
 - ``start_planning``
 - ``propose_plan``
+- ``plan_template``
 - ``upsert_plan``
 - ``list_plan_versions``
 - ``show_plan``
@@ -85,6 +90,7 @@ Question API
 ------------
 
 - ``add_question``
+- ``add_questions``
 - ``answer_question``
 - ``answer_questions``
 - ``list_questions``
@@ -97,6 +103,7 @@ Run API
 
 - ``start_implementation``
 - ``restart_implementation``
+- ``resume_implementation``
 - ``log_implementation``
 - ``add_implementation_deviation``
 - ``add_implementation_artifact``
@@ -143,6 +150,14 @@ Handoff API
 - ``close_handoff_api``
 - ``cancel_handoff_api``
 
+Release API
+~~~~~~~~~~~
+
+- ``build_changelog_context``
+- ``list_release_records``
+- ``show_release``
+- ``tag_release``
+
 Search API
 ~~~~~~~~~~
 

{taskledger-0.1.0 → taskledger-0.1.2}/docs/architecture_taskledger_split.rst

@@ -32,7 +32,7 @@ Command surface
 ---------------
 
 The supported command groups are ``task``, ``plan``, ``question``, ``implement``,
-``validate``, ``todo``, ``intro``, ``file``, ``link``, ``require``, ``lock``,
-``handoff``, ``context``, ``actor``, ``view``, ``next-action``, ``can``, ``search``,
-``grep``, ``symbols``, ``deps``, ``doctor``, ``repair``, ``reindex``, ``init``,
-``status``, ``export``, ``import``, and ``snapshot``.
+``validate``, ``todo``, ``intro``, ``file``, ``link``, ``require``, ``release``,
+``lock``, ``handoff``, ``context``, ``actor``, ``view``, ``next-action``, ``can``,
+``search``, ``grep``, ``symbols``, ``deps``, ``doctor``, ``repair``, ``reindex``,
+``init``, ``status``, ``export``, ``import``, and ``snapshot``.

{taskledger-0.1.0 → taskledger-0.1.2}/docs/command_contract.rst

@@ -27,6 +27,7 @@ when explicitly targeting another task.
 
    taskledger plan start
    taskledger plan start --task task-0001
+   taskledger implement resume --task task-0001 --reason "Reacquire implementation lock."
    taskledger implement restart --task task-0001 --summary "Fix validation findings."
    taskledger implement finish --task task-0001 --summary "Implemented."
    taskledger validate status --task task-0001
@@ -41,10 +42,29 @@ Positional refs are reserved for the direct resource being changed or shown:
 .. code-block:: bash
 
    taskledger task activate TASK_REF
+   taskledger task follow-up PARENT_REF TITLE [options]
    taskledger todo done TODO_ID --task TASK_REF --evidence "pytest -q"
    taskledger question answer QUESTION_ID --task TASK_REF --text "Yes."
    taskledger handoff show HANDOFF_ID --task TASK_REF
    taskledger require add REQUIRED_TASK_REF --task TASK_REF
+   taskledger release show 0.4.1
+
+Release commands
+----------------
+
+Release boundaries are durable project records, not task lifecycle states:
+
+.. code-block:: bash
+
+   taskledger release tag 0.4.1 --at-task task-0030 --note "0.4.1 released"
+   taskledger release list
+   taskledger release show 0.4.1
+   taskledger release changelog 0.4.2 --since 0.4.1 --until-task task-0035 --output /tmp/taskledger-0.4.2-changelog-source.md
+
+``release tag`` writes a durable release record under ``.taskledger/releases/``.
+``release changelog`` is read-oriented: it renders Markdown or JSON changelog
+context from done tasks and may write an external output file, but it does not
+mutate ledger state.
 
 ``next-action`` result contract
 -------------------------------
@@ -79,6 +99,9 @@ and may also include:
 * ``next_item`` for the concrete target
 * ``commands`` for ordered command hints with one primary command
 * ``progress`` for question, todo, or validation queues
+* ``template_command`` plus ``required_plan_fields`` and
+  ``recommended_plan_fields`` when the next step is regenerating a plan from
+  answered questions
 
 Agents should inspect ``next_item``, prefer ``next_command`` when it is safe,
 avoid inventing question answers, and never mark todos done without evidence.
@@ -86,6 +109,39 @@ avoid inventing question answers, and never mark todos done without evidence.
 When a task is in ``failed_validation``, ``next-action`` should direct agents
 back to implementation with ``taskledger implement restart --summary SUMMARY``.
 
+When a task persists ``planning``, ``implementing``, or ``validating`` as its
+status but ``active_stage`` is missing, ``next-action`` must not report
+``The task is cancelled.`` For an orphaned implementation with a still-running
+latest implementation run and no active lock, it should direct agents to
+``taskledger implement resume --task TASK_REF --reason "..."``.
+For an approved task with a non-implementation run still marked running,
+``next-action`` must not direct agents to ``taskledger implement start``.
+It should report a repair-oriented action and point to ``taskledger doctor``.
+Truly cancelled tasks recover through ``taskledger task uncancel --reason "..."``
+to a durable non-active stage rather than directly re-entering an active stage.
+
+Run and lock repair
+-------------------
+
+``taskledger doctor`` and ``taskledger doctor locks`` report running runs without
+matching active locks. Orphaned running planning runs can be finished only
+through an explicit repair command with a reason:
+
+.. code-block:: bash
+
+   taskledger repair run --task TASK_REF --run RUN_ID --reason "Planning was already completed."
+
+The repair command refuses to finish non-planning runs, non-running runs, or
+runs that still have a matching active lock.
+
+Post-completion follow-up deltas
+--------------------------------
+
+``taskledger task follow-up PARENT_REF TITLE`` is the supported path for small
+post-completion changes. It requires a ``done`` parent task, creates a new draft
+child task with ``parent_task_id`` and ``parent_relation=follow_up``, and keeps
+the parent task terminal.
+
 Human monitoring UI
 -------------------
 

{taskledger-0.1.0 → taskledger-0.1.2}/docs/full_task_cycle.rst

@@ -279,13 +279,32 @@ After validation passes, close the task and inspect final state:
    taskledger task dossier --format markdown
    taskledger handoff create --mode validation --summary "Parser fix is implemented and validated."
    taskledger handoff show HANDOFF_ID --format text
-   taskledger task close --summary "Fixed parser delimiter handling and validated parser regressions."
+   taskledger task close --note "Fixed parser delimiter handling and validated parser regressions."
+   taskledger release tag 0.4.2 --at-task parser-fix --note "0.4.2 released."
    taskledger task show
    taskledger status --full
    taskledger doctor
 
-``task close`` marks the task done. The dossier and handoff commands preserve a
-fresh-context summary for future agents or reviewers.
+After validation passes, the task is in ``done`` state. ``task close`` is a
+final acknowledgement command for an already-done task. Release boundaries are
+tracked by ``taskledger release tag``. The dossier and handoff commands preserve
+a fresh-context summary for future agents or reviewers.
+
+Post-completion follow-up deltas
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When the original task is complete and a later small delta is needed, keep the
+parent task closed and create a new follow-up child task:
+
+.. code-block:: bash
+
+   taskledger task follow-up parser-fix "Rename parser error copy" --description "Small post-completion delta." --activate
+   taskledger plan start
+   taskledger plan upsert --file ./plan.md
+   taskledger plan accept --version 1 --note "Approved tiny follow-up delta."
+
+Use the normal lifecycle on the follow-up task. Do not reopen the completed
+parent task for ordinary deltas.
 
 11. Recovery And Maintenance Commands
 -------------------------------------
@@ -298,6 +317,8 @@ cycle:
    taskledger lock show
    taskledger doctor locks
    taskledger lock break --reason "Recover stale planning lock."
+   taskledger implement resume --reason "Reacquire implementation lock for existing running run."
+   taskledger task uncancel --reason "Restore the task to a safe durable stage."
    taskledger repair index
    taskledger repair task --reason "Inspect task record after manual edit."
    taskledger reindex
@@ -305,4 +326,10 @@ cycle:
    taskledger snapshot ./taskledger-snapshot --include-bodies --include-run-artifacts
 
 Locks are never cleared silently. Use ``lock break`` only after inspecting the
-lock and recording a reason.
+lock and recording a reason. If a broken stale lock leaves an implementation run
+still marked ``running``, continue with ``implement resume`` instead of starting a
+new implementation run. If a task is truly ``cancelled``, use ``task uncancel``
+to restore a safe durable stage before re-entering planning, implementation, or
+validation through the normal stage-specific commands. After ``task uncancel``,
+run ``next-action`` again; if it reports ``implement-resume``, reacquire the
+existing implementation run rather than running ``implement start``.

{taskledger-0.1.0 → taskledger-0.1.2}/docs/public_surface.rst

@@ -11,7 +11,7 @@ Supported CLI groups
 --------------------
 
 - ``task``, ``plan``, ``question``, ``implement``, ``validate``, ``todo``
-- ``intro``, ``file``, ``link``, ``require``, ``lock``, ``handoff``
+- ``intro``, ``file``, ``link``, ``require``, ``release``, ``lock``, ``handoff``
 - ``doctor``, ``repair``, ``next-action``, ``can``, ``reindex``
 - ``init``, ``status``, ``export``, ``import``, ``snapshot``
 - ``context``, ``view``, ``serve``, ``search``, ``grep``, ``symbols``, ``deps``
@@ -20,18 +20,26 @@ Supported CLI groups
 keep using the CLI and JSON command surface for automation.
 
 The supported implementation lifecycle includes ``implement restart --summary
-"..."`` when a task is in ``failed_validation``.
+"..."`` when a task is in ``failed_validation`` and ``implement resume --reason
+"..."`` when an existing running implementation run has lost its lock.
+
+Small post-completion deltas use ``task follow-up PARENT_REF TITLE`` to create a
+new child task instead of reopening a ``done`` task.
+
+Release boundaries are tracked separately from task lifecycle state with
+``release tag`` and ``release changelog``.
 
 question subcommands
 --------------------
 
 - ``question add``, ``question list [--status STATUS]``, ``question answers [--format markdown|json]``
+- ``question add-many [--text TEXT|--yaml-file PATH] [--required-for-plan]``
 - ``question answer``, ``question answer-many``, ``question dismiss``, ``question open``, ``question status``
 
 plan subcommands
 ----------------
 
-- ``plan start``, ``plan propose``, ``plan upsert``, ``plan lint``, ``plan approve``, ``plan accept``, ``plan reject``, ``plan show``, ``plan diff``
+- ``plan start``, ``plan propose``, ``plan template``, ``plan upsert``, ``plan lint``, ``plan approve``, ``plan accept``, ``plan reject``, ``plan show``, ``plan diff``
 - ``plan regenerate --from-answers``, ``plan materialize-todos``, ``plan command -- ...``
 
 todo subcommands
@@ -51,11 +59,14 @@ Supported Python API modules
 - ``taskledger.api.introductions``
 - ``taskledger.api.locks``
 - ``taskledger.api.handoff``
+- ``taskledger.api.releases``
 - ``taskledger.api.search``
 
 ``taskledger.api.task_runs`` includes the public lifecycle helpers
-``start_implementation``, ``restart_implementation``, ``start_validation``, and
-``finish_validation``.
+``start_implementation``, ``restart_implementation``, ``resume_implementation``,
+``start_validation``, and ``finish_validation``. ``taskledger.api.tasks`` also
+exposes ``uncancel_task`` for restoring truly cancelled tasks to a safe durable
+stage.
 
 Removed legacy surfaces
 -----------------------