[mvalancy]

Fixes the semantic-lod red from #281's CI (run 42995673129, attempt 1). Its no-writes window saw CreateStarterItems and UpdateGraph.

Cause

• The shared admin user's example workspace (Zoom out: labelled levels from items to graph to sibling graphs to projects, with an example project for new users #277) was left unfinished when an earlier spec closed its browser context.
• At the next sign-in, the app finished it in the background, as Example project: resume without races (#277) #282 designed.
• The example's tag and count updates and its duplicate delete used the views' own UpdateGraph/DeleteGraph, so the test couldn't tell them from navigation writes.

Fix

• Those writes now use UpdateStarterGraph and DeleteStarterGraph. All six writes the example makes are listed exactly in EXAMPLE_WRITE_OPERATIONS (packages/web/src/lib/exampleOperations.ts).
• Every spec that blocks and counts writes for the shared admin user lets exactly those through and still counts everything else: semantic-lod, nested-semantic-lod, inspector-readability, item-wire-consumers, local-item-lod, item-symbols, large-graph-symbols and relationship-priority. Blocking the example there may also be what left it unfinished for the next spec.

Tests

• GraphContext.test.tsx now records the mutations it sees. It asserts that the create, resume-with-duplicates and failure-count paths write only …Starter… operations.
• The assertions fail on the previous GraphContext.tsx, which sent UpdateGraph ×7. A resume test with an empty duplicate and a renamed pending part covers DeleteStarterGraph and setTags: reverting either call fails it. GraphContext passes 7/7.
• tsc is clean, and the lint counts are unchanged.

🤖 Generated with Claude Code

[github-actions]

🧪 Comprehensive Test Suite

• Unit suites (Node 22.18.0 & 24.x) — core, web, server, mcp-server: ✅ passed
• Installer & deploy config: ✅ passed

Full-stack smoke gate runs in the CI workflow.

[mvalancy]

Independent review (35db991)

vitest run src/contexts/GraphContext.test.tsx passes 6/6. With the new test file on the old dev code, 3 tests fail (UpdateGraph seen), so the guard is real.

Checked, no problem found

• All five example graph writes are renamed: setCounts, setTags, the duplicate deleteGraph, countExampleFailure and the abandoned-tag clear. The views' own create, update and delete calls (GraphContext.tsx ~565/617/671) still use CreateGraph/UpdateGraph/DeleteGraph. No code outside the example uses Starter in an operation name.

• The narrower selection loses nothing:

  • it returns every field the input sets (tags, nodeCount, edgeCount, lastActivity);
  • the hooks have no update or refetchQueries option;
  • the offline link picks a handler by root field, not by operation name;
  • errorLink's /workitem|edge|graph/i still matches both new names;
  • writeStarter ends with refetchGraphs.

  Only updatedAt is dropped, and nothing reads Graph.updatedAt from the cache.

Findings

1. should-fix: the tests cover 3 of the 5 renamed calls. I reverted setTags (GraphContext.tsx:243) to the views' mutation, and separately the duplicate deleteGraph (:260); each time the file stayed green at 6/6. Failure scenario: a later refactor sends the duplicate-graph delete back through deleteGraphMutation. The unit tests still pass, and semantic-lod flakes again, but only when the shared user has a duplicate example graph. One resume case would cover both: a duplicate example graph plus a non-example graph that carries the pending tag.

2. should-fix (a follow-up is fine): four other specs have the same no-write check for the shared ADMIN user, and they still abort every mutation:

   • nested-semantic-lod.spec.ts:114
   • inspector-readability.spec.ts:139
   • item-wire-consumers.spec.ts:49 and :401
   • local-item-lod.spec.ts:160

   They flake the same way. Aborting the example's writes (and its failure count) there can also be what leaves the example unfinished for the next spec. A shared isExampleWrite(body) helper in tests/lib, used by all five specs, would fix both.

3. nit: semantic-lod.spec.ts:129 accepts Starter anywhere in the operation name. An exact set of the six example operations would stop a future view mutation named, say, ApplyStarterTemplate from slipping past the check.

🤖 Generated with Claude Code

[mvalancy]

Thanks. All three findings are addressed in 2b27dac:

1. setTags and duplicate delete untested: a new GraphContext test resumes with an empty duplicate "Fix bugs" graph and a renamed pending part. It asserts that the duplicate is removed and that the renamed part keeps its other tags. I reverted setTags, and then separately the duplicate delete, to the views' operation names. Each revert now fails that test. GraphContext tests pass 7/7.
2. Other specs blocking writes: EXAMPLE_WRITE_OPERATIONS and isExampleWrite now live in packages/web/src/lib/exampleOperations.ts. Every spec that blocks and counts writes uses them. That's the four you listed plus three more I found: item-symbols, large-graph-symbols and relationship-priority. They let only the example's writes through and still count everything else.
3. Loose match: it's an exact match on the six operation names now, not a Starter substring. The GraphContext tests fail if the example sends any write outside that list.

🤖 Generated with Claude Code

[github-actions]

🧪 Comprehensive Test Suite

• Unit suites (Node 22.18.0 & 24.x) — core, web, server, mcp-server: ✅ passed
• Installer & deploy config: ✅ passed

Full-stack smoke gate runs in the CI workflow.

[github-actions]

🧪 Comprehensive Test Suite

• Unit suites (Node 22.18.0 & 24.x) — core, web, server, mcp-server: ✅ passed
• Installer & deploy config: ✅ passed

Full-stack smoke gate runs in the CI workflow.

[github-actions]

🧪 Comprehensive Test Suite

• Unit suites (Node 22.18.0 & 24.x) — core, web, server, mcp-server: ✅ passed
• Installer & deploy config: ✅ passed

Full-stack smoke gate runs in the CI workflow.