{
  "feature_name": "controller-status",
  "created_at": "2026-06-19T00:00:00Z",
  "updated_at": "2026-07-17T11:15:00Z",
  "language": "en",
  "phase": "implementation-complete",
  "approvals": {
    "requirements": {
      "generated": true,
      "approved": true
    },
    "design": {
      "generated": true,
      "approved": true
    },
    "tasks": {
      "generated": true,
      "approved": true
    }
  },
  "ready_for_implementation": true,
  "implementation": {
    "completed": true,
    "tasks_done": "1.1-5.1 (all)",
    "notes": "ctrlstatus opcode + handler + all-roles dispatch gate + libxce any-node & authoritative reads + ctrlstatus command + wait-primary swap, all reviewed and committed; E2E-verified live (primary self-reports, standbys answer with answered-by, config SHA-256 checksum identical across nodes, authoritative wait-primary names the primary). E2E found+fixed the primaryName-from-vestigial-primary_host bug. Out-of-boundary upstream finding: libxce failover returns EINVAL on a dead-first-master (affects joblist equally) -> route to libxce-failover."
  },
  "delta": {
    "reopened_at": "2026-06-20T00:00:00Z",
    "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.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."
    ]
  }
}