Skip to content

feat: define and persist native plan artifacts - #79

Closed
jefft72 wants to merge 3 commits into
mainfrom
plan/01-persistence
Closed

jefft72 wants to merge 3 commits into
mainfrom
plan/01-persistence

Conversation

@jefft72

@jefft72 jefft72 commented Aug 16, 2026

Copy link
Copy Markdown
Contributor

Summary

Introduces the persistent foundation for native plan mode.
A plan is now a first-class session artifact with a stable shape, a submit_plan tool that produces it, and session entries that record collaboration-mode changes, submitted plans, and their resolutions.

Replaces #63, which could not build against main.

Reasoning

Plan mode is only useful if an accepted plan survives resume and tree navigation, so persistence has to come before any runtime or UI behaviour.
Modelling the plan as a session entry rather than transient state means the active branch determines the pending plan, which keeps resume and fork correct without a separate store.

The entry parser deliberately does not normalize session headers here.
That helper belongs to the task profile stack, and plan mode must build on main without it.

Changes

  • Adds core/plan-mode.ts with PlanArtifact, PlanResolution, CollaborationMode, and the submit_plan tool definition
  • Adds plan, plan_resolution, and collaboration_mode_change session entries with strict parsing that rejects malformed artifacts
  • Threads plan state through branch summarization so compaction preserves it
  • Adds coverage for the plan tool and for plan entry persistence

Testing

  • npx vitest --run test/plan-mode-tools.test.ts test/session-manager/file-operations.test.ts
  • tsgo --noEmit reports zero errors
  • biome check . clean

Define validated plan artifacts and the intrinsic submit_plan tool so every runtime uses one normalized, bounded representation for planning output.
Persist collaboration mode, submitted plans, resolutions, and accepted continuations through validated append-only session history and branch replay.
- The plan persistence work called normalizeSessionHeader, which is defined only on the task profile stack, so the entry parser did not compile against main
- Returning the parsed entry directly keeps plan artifact parsing intact and leaves relatedSessions normalization to the stack that owns it
@Pepps233
Pepps233 self-requested a review August 16, 2026 18:49
@Pepps233 Pepps233 added enhancement New feature or request coding-agent labels Aug 16, 2026
@Pepps233
Pepps233 requested a review from Issacboy123 August 16, 2026 18:51

@Issacboy123 Issacboy123 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The explicit PlanArtifact lifecycle and one-shot continuation model looks good. The continuation still treats raw Markdown as approved even though a host can render only part of it, such as omitting a link title. I think you should one canonical approved representation for both the UI and implementation. This issue remains in the rest of the stack.


# ${plan.title}

${plan.markdown}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This raw Markdown is placed under an assertion that the user approved it, but a rendered approval view may omit source metadata such as link titles. Use a canonical representation identical to the approved view, or reject/display every non-visible Markdown field before acceptance.

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

Labels

coding-agent enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants