{
  "feature_name": "admin-config-tool",
  "created_at": "2026-07-06T01:30:00Z",
  "updated_at": "2026-08-16T00:00: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,
  "blocked_on": [
    "RESOLVED 2026-07-25 (bug-1468, commit 959b0cda): controller OP_upgradeConfig dispatch defect (cluster.c) -- myreq_handler's dispatch guard was inverted (introduced by commit fd93997f, 2026-05-31), rejecting the only role that could ever legitimately reach it and making handle_upgrade_config() permanently unreachable from any network client. Fixed by config-upgrade-snapshot task 8.6 (which independently hit the same wall building a live OP_upgradeConfig sender). The controller-side path this blocker described has since been exercised live and successfully many times via config-upgrade-snapshot's --config-upgrade soak. push_config() itself (xceadmin's TLS/redirect/framing code) remains mock-tested only -- a live `xceadmin config push` run against a deployed cluster would give first-hand confirmation of the CLI's own wire code, but the blocking condition (dispatch unreachable) no longer exists.",
    "RESOLVED 2026-07-22 (bug-1461, commit e53c086): controller.capnp's struct Data shadowed the capnp builtin blob type, miscompiling UpgradeConfigRequest.sha256/.bytes — fixed at the schema root (renamed to XceData), unblocking push_config()'s request construction. The dispatch defect above (bug-1468) is a separate issue and is now ALSO resolved (see entry above) — push_config() remains mock-tested only, no live xceadmin-specific E2E run yet, but nothing blocks one."
  ],
  "gitea": {
    "milestone_id": 1,
    "issues": {
      "requirements_design": 22,
      "implementation": 23,
      "validation": 24
    }
  },
  "validate_impl": {
    "decision": "GO",
    "validated_at": "2026-08-16T00:00:00Z",
    "note": "Corrected stale phase metadata (was 'tasks-generated' though 20/21 tasks were already [x] complete). Task 6.3's remaining blocker -- bug-1485's ~24/25 flaky primary-push failure -- was already followed up (2026-08-01): DEVNULL stderr redirect replaced with real per-node log capture, test re-run 40x standalone with zero reproductions and zero captured crash evidence. Decision reached: mergeable as-is, bug-1485 downgraded to low-priority/environment-flake rather than a blocker. Task 6.3 now marked [x] complete.",
    "known_limitations": [
      "bug-1485: primary-push E2E test (test_e2e_live_ha_push.py) had a ~24/25 flaky failure rate in one investigation round (elected primary observed <defunct> shortly after promotion) that could not be reproduced in 40 clean standalone runs; left OPEN as a low-priority environment-flake, not closed, since absence of reproduction here is not proof of absence. Real stderr capture is now permanently in place to diagnose any recurrence.",
      "6.2's own finding stands: a genuinely single-node config push always exits 1 (ackedCount == 0, no standbys to ACK) even on full server-side success -- spec-consistent per cli.py/design.md's exit-0-iff-acked_count>0 postcondition, not a regression, but a future task may want a distinct single-node success signal.",
      "push_config()'s TLS/redirect/framing code has had live E2E coverage only against the single-node (6.2) and 3-node (6.3) topologies exercised in this spec's own tests -- no production/CI live run yet."
    ]
  }
}