tegwick
2b5d8f90f8
C-04 ran once per file, so the three custodian-WP-0003 views and their archived parent flipped the shared row's status on every run. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 57383@bnt-lap001 Assistant-Session: ef71febe-2a37-4c34-a979-2508ca973c91
1.2 KiB
| id | type | title | domain | repo | status | owner | topic_slug | created | updated |
|---|---|---|---|---|---|---|---|---|---|
| STATE-WP-ADHOC-2026-10-06 | workplan | Ad hoc fixes — 2026-10-06 | infotech | state-hub | finished | claude-code | state-hub | 2026-10-06 | 2026-10-06 |
Stop historical split views from writing their parent's status
id: STATE-WP-ADHOC-2026-10-06-T01
status: done
priority: medium
Activity's custodian-WP-0003a/b/c split views carry the archived parent's UUID
b4eb45a9-69e3-4ab0-b00c-67a53c3117c5. C-04 ran per file, so each
fix-consistency run set the shared row to whichever file it processed last.
On 2026-10-06 it flipped finished → archived → finished. The parent file
says archived; the views say done. C-04 and the frontmatter C-20 now skip
bound historical views (historical_view_paths from historical_projection
BINDINGS), so only the parent file supplies the row. This matches Forge
receiving, which takes the row from the parent only and gives historical
workplans no edges. A direct consistency_check.py --repo activity-core --fix
set the parent back to archived, and a re-run reports nothing to fix. UUIDs
and tasks were untouched. Unblocks RMGR-WP-0019-T03 (see STATE-WP-0095).