Skip to content

Port implementation status and lazy snapshots from #460 - #512

Open
MaggieAppleton wants to merge 3 commits into
mainfrom
port-460-snapshot
Open

MaggieAppleton wants to merge 3 commits into
mainfrom
port-460-snapshot

Conversation

@MaggieAppleton

@MaggieAppleton MaggieAppleton commented Oct 12, 2026 •

Copy link
Copy Markdown
Collaborator

Ports two backend pieces from @Krzysztof-Cieslak's #460. Both commits carry his co-author trailer.

#460 will be closed. Its interactive task-graph UI and workspace picker are superseded: the team chose #508's Build capsule and view, and #451's rule that work runs on whoever clicks Build. These two pieces stand on their own and are worth keeping.

What is kept

  1. hasGraph on implementation status. Plan.ImplementationStatus (protocol first) gains hasGraph: boolean, and implementationStatus() derives it from the latest graph version's tasks. It rides on plan:implementation and the plan:open reply, so a client can tell a graph exists without fetching a full snapshot. Krzysztof's test checks that it publishes only after the durable commit and survives reopening.
  2. useImplementationSnapshot (apps/web/src/implementation-snapshot.ts) plus implementationResponse. Full snapshots load only while an implementation view is active; stale responses are ignored by room and revision; it refreshes on plan:implementation, plan:open, plan:update and experiment:changed. Build adopts it in place of its inline fetch and refresh logic, with the same behaviour, including auto-draft deciding once per entry into Build.

hasGraph has no consumer yet: room-workspace's plan:implementation handler only uses locked, and Build reads the full snapshot. It is left as an available field (room-workspace's initial status just includes hasGraph: false).

Merge order

This intentionally merges after the living-document stack (#451 → #452 → #453 → #508 → #510 → #454 → #457 → #466). #508 rewrites build-view.tsx, so this will be rebased onto main then and the hook re-adopted in the new Build view.

flowchart LR
  A[Build view active?] -- no --> Z[No fetch; in-flight request aborted]
  A -- yes --> F[GET /api/channels/:room/implementation]
  F --> S{Same room and older revision?}
  S -- yes --> X[Ignore stale response]
  S -- no --> U[Set snapshot, call onLoad]
  W[plan:implementation / plan:open / plan:update / experiment:changed] --> R[refresh: abort current, refetch]
  R --> F
Loading

Tests

  • bun test apps/server/src/tasks apps/web/src/build* (69 pass, includes new notifications.test.ts)
  • bun test full: all pass except three design-token/icon audits that flag local, uncommitted design-jig files
  • bun run types clean
  • bun run ci: only a design-jig CSS custom-property finding (local jig file, not in this PR)
  • bun run e2e e2e/implementation-launcher.e2e.ts: 11 passed, 1 skipped

🤖 Generated with Claude Code

MaggieAppleton and others added 3 commits October 12, 2026 11:59
plan:implementation and the plan:open reply now carry hasGraph, derived
from the latest graph version, so clients can tell a graph exists without
fetching a full implementation snapshot. Ported from #460.

Co-authored-by: Krzysztof Cieslak <krzysztof_cieslak@windowslive.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
useImplementationSnapshot fetches the full snapshot only while an
implementation view is active, ignores stale responses by room and
revision, and refreshes on implementation, open, update and experiment
frames. Build adopts it in place of its inline fetch with the same
behaviour. Ported from #460.

Co-authored-by: Krzysztof Cieslak <krzysztof_cieslak@windowslive.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@MaggieAppleton
MaggieAppleton marked this pull request as ready for review October 12, 2026 11:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant