Skip to content

Plan integration 2: Centralize mutations and checkpoints #9

Closed

Description

@NetDevAutomate

Parent

What to build

Route create, revision, document replacement, milestone changes, lifecycle changes, evaluation, and deletion through PlanApplication so CLI and Web share one policy implementation.

Acceptance criteria

  • CLI and Web no longer mutate Study Plans directly through the persistence layer.
  • Plan identifier and creation time survive revisions and validated document replacement.
  • Milestone changes set an explicit done value and are idempotent under retries.
  • Checkpoint results distinguish complete recording from partial Markdown or SQLite writes.
  • Deletion retains checkpoint history and returns an immutable result view.
  • Transport adapters map shared domain failures without reimplementing lifecycle policy.

Blocked by

Definition of Done

  • All remaining existing CLI and Web lifecycle paths use PlanApplication.
  • An architecture test prevents CLI, Web, and MCP adapters from importing mutable store operations.
  • Store, evaluation, CLI plan, and Web plan suites pass.
  • Partial checkpoint failures have regression coverage.
  • Capability specs and docs reflect the centralized lifecycle contract.

Activity

  1. added
    ready-for-agentImplementation-ready specification with settled requirements and test seams
    on Sep 4, 2026
  2. NetDevAutomate commented on Sep 18, 2026

    @NetDevAutomate
    OwnerAuthor

    Status: met on the evidence below. Source: docs/architecture/plan-integration/receipts/issue-closeout-draft-2026-09-16.md, re-verified against main at a5b9f903 (2026-09-18); commit SHAs are those on main. Legend as on #8.

    Acceptance criterion Met Evidence
    CLI and Web no longer mutate Study Plans directly through the persistence layer yes T: test_architecture_plan_seam.py (guard + 14 planted bypasses rejected; C: 5693e35c, review-2 G7 C: 59ab1e23); rg 'readiness\(|save_plan' web/routes/plans.py → 0
    Plan identifier and creation time survive revisions and validated document replacement yes T: test_plan_application.py::test_replace_preserves_id_and_created, ::test_revise_preserves_id_and_created_and_bumps_updated
    Milestone changes set an explicit done value and are idempotent under retries yes, for the explicit-state operations T: test_plan_application_mutations.py::test_set_milestone_done_is_idempotent, ::test_set_unknown_milestone_raises_invalid_milestone; the seam's SetMilestone, the CLI's --done/--undone and the MCP tool are sets. Not the legacy Web toggle request (POST …/milestones/{i}/toggle, read-invert-write) nor the no-flag CLI form — both documented as toggles (S: web-ui "The milestone checkbox is one SetMilestone; the toggle request is not replay-safe"; docs/study-plans.md "Recording, retries, and deletion")
    Checkpoint results distinguish complete recording from partial Markdown or SQLite writes yes Bug B C: e74c2a63 + T: test_planning_evaluation.py::test_failed_checkpoint_db_write_is_reported_as_a_warning, ::test_successful_checkpoint_db_write_adds_no_warning; T: test_plan_application_mutations.py::test_assess_db_failure_reports_failed_sink_and_returns_evaluation, ::test_assess_document_failure_reported_independently; review-2 G8 both-sinks-failed (C: def5c561)
    Deletion retains checkpoint history and returns an immutable result view yes T: test_plan_application_mutations.py::test_delete_retains_checkpoint_history, ::test_delete_returns_delete_result_and_document_gone, ::test_delete_without_confirm_raises_invalid_field
    Transport adapters map shared domain failures without reimplementing lifecycle policy yes T: test_cli_plan_seam.py (36 today), T: test_web_plans_seam.py (14), T: test_mcp_plan_record_seam.py (7)

    DoD. T: test_plan_recording_failures.py (6) covers partial checkpoint failures on an isolated database; the store/evaluation/CLI-plan/Web-plan suites are green in the verify receipt's plan-suites check (518 in R: receipts/verify-d0251fd1.json) and in CI on main (run 35374196645, 15/15).

    Since the draft (2026-09-17/18): the mission (why, success, constraints, out_of_scope) is now a revisable field of RevisePlan on the MCP and Web doors (follow-on item 3b, C: 653e825b), judged by the same readiness gate as every other field; the CLI does not expose it, by decision.

    Landed via #20 (2026-09-17). Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    ready-for-agentImplementation-ready specification with settled requirements and test seams

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions