design_docs/tools/operationalize_design.py --close: defers non-closed children then fails to close the epic anyway nf-kccf ← Beads

Twinned from https://github.com/cfsh/ninefold/issues/1196 by tools/beads/import_github.py's reconcile pass.

\close()\ (design_docs/tools/operationalize_design.py:496-523) sets every non-closed child to \deferred\, then calls \bd.close(epic_id, reason=...)\ with no \--force\:

\\\`python deferred = 0 for issue in bd.list_issues(parent=epic_id, include_closed=True): if issue.get("status") == "closed": continue bd.update_status(issue["id"], "deferred") deferred += 1

bd.close(epic_id, reason=f"design {doc_id} closed") \\\`

bd's own \close\ command blocks on any child that isn't literally \closed\ — \deferred\ doesn't count, even though the function just wrote that status itself moments earlier:

\\\` cannot close epic nf-tvc: 1 open child issue(s); close children first or use --force to override \\\`

Hit live closing out design 011 (nf-tvc): T9 was legitimately \deferred\ (Aedan's own backup-direction call), the script correctly left it that way, then died trying to close the epic anyway. Worked around by hand: \bd close nf-tvc --reason "..." --force\ directly.

This is the second time bd's real close-blocking semantics have surfaced a \deferred\-vs-\closed\ gap in this design's own tooling — see #1191 for the sibling bug in \import_github.py\'s reconcile. Fix: \close()\ should pass \--force\ on its own \bd.close(epic_id, ...)\ call (it already validated/wrote every child's terminal status itself, so overriding bd's generic child-blocking check here is correct, not a bypass) — or \Bd.close\ should grow a \force=\ kwarg if it doesn't already have one convenient to call from Python.