docs(controller-status): record first /kiro-validate-impl pass -- GO

All tasks (1.1-6.4) were already [x] with no prior validate_impl
record. Fixed stale delta.impl_status (still said task 6.4 blocked on
sandbox overlayfs despite tasks.md recording it VERIFIED live since
2026-07-02).

Full suite 9/9 green, 36/36 requirement acceptance criteria mapped,
cross-task wire contract verified field-for-field end to end (schema
-> typemap -> handler -> dispatch -> libxce client -> CLI), two live
smoke runs (3-round sequential HA soak + targeted 3-node deploy
exercising Req 10/11 directly) both PASS. One transient test failure
during the run traced to a concurrent second session competing for
the same build directory, not a regression -- reproduced clean 3x in
isolation.
This commit is contained in:
Rongsong Shen 2026-07-17 11:01:48 +00:00
parent 84fde22bbd
commit c08a34866d

View file

@ -1,9 +1,9 @@
{
"feature_name": "controller-status",
"created_at": "2026-06-19T00:00:00Z",
"updated_at": "2026-06-20T00:00:00Z",
"updated_at": "2026-07-17T11:15:00Z",
"language": "en",
"phase": "tasks-generated",
"phase": "implementation-complete",
"approvals": {
"requirements": {
"generated": true,
@ -29,6 +29,14 @@
"reason": "Live E2E finding (2026-06-20): ctrlstatus answered by a standby reports committedLsn=0 / committedConfigVersion=0 while appliedLsn=38 — it reads the primary-only raw markers (persist.committed_lsn, ha->committed_config_tag) instead of the standby's learned committed position (ha->last_known_committed_lsn / last_known_committed_config_tag). Plus an observability gap: no responder timestamp to correlate a captured status against ctrl-N.log.",
"new_requirements": "10 (off-primary committed-state fidelity), 11 (responder snapshot timestamp for log correlation)",
"needs": "design + tasks regen for Req 10-11 only; prior tasks 1.1-5.1 remain implemented",
"impl_status": "6.1-6.3 implemented + reviewed + committed (65ddafe, 3799bd6, ee30765), controller unit suite green; 6.4 (live-cluster E2E) BLOCKED on manual real-fs env — sandbox overlayfs fdatasync errno=5 (bug-795) breaks the commit path. Hand-off recipe in tasks.md Implementation Notes."
"impl_status": "6.1-6.4 all implemented + reviewed + committed and complete. 6.4 (live-cluster E2E), previously blocked on the sandbox overlayfs fdatasync issue (bug-795), was VERIFIED 2026-07-02 on a real-fs (~/tmp, ext4) 3-node deploy per tasks.md's own Implementation Notes -- this field was stale until this validation pass corrected it."
},
"validate_impl": {
"decision": "GO",
"validated_at": "2026-07-17T11:15:00Z",
"note": "First post-implementation validation run -- all tasks (1.1-6.4) were already [x] with no prior validate_impl record, and this delta block's impl_status field had gone stale (still said 6.4 BLOCKED despite tasks.md recording it VERIFIED since 2026-07-02). Full suite 9/9 green (one transient ASAN failure during the run was traced to a concurrent second session competing for the same build directory, not a regression -- reproduced clean 3x in isolation), 36/36 requirement acceptance criteria mapped, cross-task wire contract verified field-for-field end to end (schema -> typemap -> handler -> dispatch -> libxce client -> CLI), two live smoke runs (a 3-round sequential HA soak plus a targeted live 3-node deploy exercising Req 10/11 directly) both PASS.",
"known_limitations": [
"A live observation during smoke testing: querying ctrlstatus on a standby within <1s of a fresh submit can show appliedLsn > committedLsn. This is the documented, in-boundary staleness caveat from design.md's Locked Decision #2 (last_known_committed_lsn refreshes only at CtrlHello join/RDHUP, not per-heartbeat) -- explicitly anticipated and accepted at design time, not a regression of the original zero-value bug this spec's delta phase fixed."
]
}
}