@trycore/spec-build-harness 0.13.0 → 0.14.1

package/hooks/build/lib/runtime-ops.sh

@@ -108,6 +108,13 @@ ops_path_front_integration() { echo "/fronts/$1/members/$2/integration"; }
 ops_path_mirror() { echo "/projects/$1/mirror/transitions"; }
 ops_path_proposals() { echo "/projects/$1/context/agent-proposals"; }
 
+# [#62] Propuesta de épica (hub#113/#114). El agente PROPONE; el hub decide la identidad
+# (`EP-XXX`) al aprobar y un humano aprueba: por eso hay una ruta de creación y otra de
+# consulta, y ninguna de publicación. Mismo patrón que las propuestas de asset
+# (`ops_path_proposals`), que es su precedente en este cliente.
+ops_path_epic_proposals() { echo "/projects/$1/epic-proposals"; }
+ops_path_epic_proposal() { echo "/projects/$1/epic-proposals/$2"; }
+
 ops_mode() { runtime_mode; }
 
 # ops_slice_id — id del slice activo según la caché de proyección ("" si no hay).
@@ -289,3 +296,104 @@ PY
     *) return 5 ;;
   esac
 }
+
+# ── Ledger local de propuestas de épica [#62] ────────────────────────────────────────
+# Memoria del ciclo «propongo → un humano aprueba → escribo el fichero con el código del
+# hub». Vive fuera de build-state.json a propósito: en modo `runtime` ese fichero no es la
+# fuente de verdad, y el ledger no es estado del pipeline sino el rastro de una conversación
+# con el hub. Clave estable: `client_event_id` (lo asigna el encolado, existe desde el primer
+# instante); `proposal_id` llega después, con el ack, y puede no llegar nunca (offline).
+ops_epic_ledger_path() { echo "$(config_root)/.claude/state/epic-proposals.json"; }
+
+# ops_epic_ledger_read — imprime {"proposals":[…]}; nunca lanza.
+ops_epic_ledger_read() {
+  local f; f="$(ops_epic_ledger_path)"
+  command -v python3 >/dev/null 2>&1 || { echo '{"proposals":[]}'; return; }
+  python3 - "$f" <<'PY' 2>/dev/null || echo '{"proposals":[]}'
+import json,sys
+try:
+    d=json.load(open(sys.argv[1]))
+    ps=d.get("proposals")
+    print(json.dumps({"proposals": ps if isinstance(ps,list) else []},ensure_ascii=False))
+except Exception:
+    print('{"proposals":[]}')
+PY
+}
+
+# ops_epic_ledger_upsert <entrada-json> — upsert por client_event_id: las claves que la
+# entrada NO menciona se conservan (así un `epic-status` puede fijar el estado sin borrar el
+# borrador que guardó `propose-epic`). Escritura atómica. rc 0/1.
+ops_epic_ledger_upsert() {
+  local entry="$1" f
+  f="$(ops_epic_ledger_path)"
+  mkdir -p "$(dirname "$f")"
+  command -v python3 >/dev/null 2>&1 || return 1
+  python3 - "$f" "$entry" <<'PY' 2>/dev/null || return 1
+import json,sys,os,tempfile
+path,entry=sys.argv[1],sys.argv[2]
+try:
+    d=json.load(open(path))
+except Exception:
+    d={}
+ps=d.get("proposals")
+if not isinstance(ps,list):
+    ps=[]
+e=json.loads(entry)
+cid=e.get("client_event_id")
+for i,p in enumerate(ps):
+    if isinstance(p,dict) and p.get("client_event_id")==cid:
+        p.update(e)
+        ps[i]=p
+        break
+else:
+    ps.append(e)
+dirn=os.path.dirname(path) or "."
+fd,tmp=tempfile.mkstemp(dir=dirn,prefix=".epic-proposals.",suffix=".tmp")
+try:
+    with os.fdopen(fd,"w") as out:
+        json.dump({"proposals":ps},out,indent=2,ensure_ascii=False); out.flush(); os.fsync(out.fileno())
+    os.replace(tmp,path)
+except Exception:
+    try: os.unlink(tmp)
+    except OSError: pass
+    raise
+PY
+}
+
+# ops_epic_ack_read <client_event_id> — el ack que dejó el carril directo, o "".
+ops_epic_ack_read() {
+  local f; f="$(runtime_outbox_dir)/acks/$1.json"
+  [ -f "$f" ] || { echo ""; return; }
+  command -v python3 >/dev/null 2>&1 || { echo ""; return; }
+  python3 - "$f" <<'PY' 2>/dev/null || echo ""
+import json,sys
+try:
+    print(json.dumps(json.load(open(sys.argv[1])),ensure_ascii=False))
+except Exception:
+    print("")
+PY
+}
+
+# ops_epic_rejected_reason <client_event_id> — razón con la que el carril directo apartó la
+# petición (o "" si no está apartada). Es lo que convierte «no pasa nada» en un diagnóstico.
+ops_epic_rejected_reason() {
+  local dir; dir="$(runtime_outbox_dir)/rejected"
+  [ -d "$dir" ] || { echo ""; return; }
+  command -v python3 >/dev/null 2>&1 || { echo ""; return; }
+  python3 - "$dir" "$1" <<'PY' 2>/dev/null || echo ""
+import json,os,sys
+d,cid=sys.argv[1],sys.argv[2]
+for name in sorted(os.listdir(d)):
+    if not name.endswith(".json"):
+        continue
+    try:
+        e=json.load(open(os.path.join(d,name)))
+    except Exception:
+        continue
+    if e.get("client_event_id")==cid:
+        print(e.get("rejected_reason") or "apartada sin razón registrada")
+        break
+else:
+    print("")
+PY
+}

package/hooks/build/scaffold-guard.sh

@@ -18,7 +18,20 @@ HERE="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 source "$HERE/lib/projection.sh"
 if [ "$(runtime_mode)" = "runtime" ]; then
   CACHE="$(runtime_projection_path)"
-  [ -f "$CACHE" ] || exit 0   # aún sin sincronizar: nada que vigilar (auto-arme)
+  if [ ! -f "$CACHE" ]; then
+    # Sin proyección hay dos casos opuestos y hay que separarlos: si el proyecto
+    # no tiene credenciales es auto-arme (aún no usa el arnés) y se deja pasar;
+    # si las tiene, este agente está DESCONECTADO del hub y seguir escribiendo
+    # código es justo lo que produce trabajo duplicado y choques entre workers.
+    if runtime_disconnected; then
+      echo "⛔ sin conexión con el hub: hay credenciales del proyecto pero no hay proyección local." >&2
+      echo "   Este agente no sabe qué trabajo tiene asignado, así que no puede escribir código." >&2
+      echo "   Recupérala con \`slice-ops.sh status\` (refresca /agent/context) y reclama con \`/build:claim\`." >&2
+      echo "   Si esto es un worktree: el estado del arnés vive en el clon principal y no viaja al worktree." >&2
+      exit 2
+    fi
+    exit 0   # auto-arme: el proyecto aún no usa el arnés, nada que vigilar
+  fi
   if ! command -v python3 >/dev/null 2>&1; then
     echo "⛔ scaffold-guard: python3 no disponible; no puedo verificar el gate de scaffold. Instala python3 (trycore-build doctor)." >&2
     exit 2