ops(0-0-0): post-reset cleanup — stale-prose fixes + protection-config memory

docs/active-trajectory.md

@@ -218,7 +218,7 @@ Per multi-AI review 2026-04-29T10:35Z: dry-run push shape verification is added
 
 Lease rejection on the real push is NOT a retry condition. It means the remote moved between observation and push — restart the safety gate from the top (re-fetch, recompute content-drift ledger, re-classify if anything moved).
 
-**Currently NOT signoff-eligible**: see the live ledger above (`unclassified_lines`, `HEURISTIC_LFG_DOMINATES` row count). The four-bucket ledger is the single source of truth for classification progress; downstream prose paragraphs are no longer hand-maintained synonyms of the ledger.
+**0/0/0 ACHIEVED 2026-04-29T14:04:50Z**: AceHack/main = LFG/main = `621aae082d70fcbf36931718ecf1b6d9e149295f`. Topology: 0 ahead, 0 behind, 0 file content diff. Old AceHack tip `675508187a5e80bd0a8c14a74a9ae80d5346e722` preserved at `archive/acehack-main-pre-000-reset-2026-04-29` on AceHack (named ref, indefinite reachability). Strict gate's classification + operational conditions all satisfied; maintainer signoff received and executed. The four-bucket ledger remains source of truth for any future drift detection.
 
 ### 9 infra files (verified 2026-04-29T09:50Z against current git state, NOT against the 16h-old plan)
 
@@ -410,7 +410,7 @@ A peer-call to Grok this session reported the inverse claim ("AceHack has the se
 
 ## Next action
 
-**Hard-reset is NOT YET signoff-eligible.** The strict gate above requires `unclassified_lines = 0`. The live four-bucket ledger above is the source of truth for the current count; the remaining files are listed in the `unclassified_lines` composition block. The next agent-owned work is per-file semantic inspection of each remaining file to either promote each to SAFE_TO_RESET_LFG_SUPERSEDES (with named evidence) or downgrade to NEEDS_FORWARD_SYNC.
+**Hard-reset complete (2026-04-29T14:04:50Z).** All gate conditions cleared; force-with-lease push executed; 0 ahead / 0 behind / 0 file diff verified. Old AceHack tip preserved at `archive/acehack-main-pre-000-reset-2026-04-29`. Next-action lane is now post-reset cleanup + INVENTORY-ONLY recovery classification of local branches/worktrees/stashes (per Amara's 7-bucket framework). Mutation gates remain on Aaron's authority for irreversible operations.
 
 ### Deferred follow-ups (NOT blocking 0/0/0 progress, captured for visibility)
 

docs/hygiene-history/ticks/2026/04/29/1410Z.md

@@ -0,0 +1 @@
+| 2026-04-29T14:10:00Z | claude-opus-4-7 | b9ccd753 | **🎯 0/0/0 ACHIEVED + post-reset cleanup PR opened.** Sequence: (1) PR #843 (final ledger-flip 235→273 / 38→0) merged 2026-04-29T13:32:27Z; classification phase complete with 273 = 273 + 0 + 0 ledger satisfied. (2) Triple-check buddy review packet ferried to Amara with 6-bucket decomposition of all 273 lines (9 infra files / 5 calibration / Batch 1-3a-3b / option-c migration); Amara approved meaningful-content-loss-free. (3) Verify-only gate packet ran 2026-04-29T13:39Z: fsck/fetch/SHA-match/content-drift/dry-run all 5/5 PASS. (4) Aaron explicit EXECUTE 13:58Z. (5) Step A succeeded — `archive/acehack-main-pre-000-reset-2026-04-29` ref preserves old AceHack tip `6755081...` indefinitely. (6) Step B FAILED first try with GH013 (repository-rules layer); after disabling ruleset, FAILED again with GH006 (legacy branch-protection layer) — discovered AceHack/Zeta had BOTH protection surfaces enforcing independently. (7) Aaron decision: DELETE legacy, leave off, restore only rulesets. (8) Path 1 v3 succeeded 2026-04-29T14:04:50Z: AceHack/main = LFG/main = `621aae082d70fcbf36931718ecf1b6d9e149295f`, 0 ahead, 0 behind, 0 file content diff. Trap-restored ruleset enforcement to active. **The pre-v1 starting line is reached.** This tick: opens post-reset cleanup PR with stale-prose fixes in active-trajectory.md (flip "Currently NOT signoff-eligible" + "Hard-reset is NOT YET signoff-eligible" to in-force 0/0/0-achieved language) + protection-config memory file documenting GH013/GH006 error mapping + legacy-deleted decision. Recovery inventory parked at `/tmp/recovery-inventory-2026-04-29.tsv` (918 branches: 123 ALREADY_REACHABLE / 795 NOT_REACHABLE; 58 worktrees all clean; 7 stashes). Awaiting Amara's recovery-classification framework before any branch/worktree mutation. Authority boundary now: reversible+in-lane → proceed; irreversible/loss/identity → ask Aaron. Cron `b9ccd753` alive. | [PR #843 merged](https://github.com/Lucent-Financial-Group/Zeta/pull/843) → [post-reset cleanup PR (next)](https://github.com/Lucent-Financial-Group/Zeta/pulls) | **Best blade across the session (Amara)**: *"The last file was not easy; it was just well-evidenced."* + *"Cross first; archaeology after."* + *"Buddies review the crossing. Claude walks the lane. Aaron decides irreversible loss."* Six rule candidates earned for post-hard-reset consolidation: Residual-Set Drift, Decision-Resolution Drift, Diff-Direction Identity Drift, Migration Preflight Ledger, Derived-Rollup Drift, Evidence-Tense Discipline + Second-Agent Design Review Gate framework + Aurora Immune Governance Extension (P2 research). Plus newly-validated authority boundary post-0/0/0: Reversible + in-lane + PR-reviewed = proceed autonomously. Irreversible loss / deletion / force-push / authority config / identity canon = ask Aaron. Inventory + provisional classification = proceed. Mutation = wait. **Aaron's quote that anchored the whole post-reset stance**: *"yeah you can relax branch prtection or tell me if you need me to and turn it back on afterwards on AceHack"* — explicit delegation of reversible config-toggle authority. |

memory/MEMORY.md

@@ -2,6 +2,8 @@
 
 **📌 Fast path: read `CURRENT-aaron.md` and `CURRENT-amara.md` first.** <!-- latest-paired-edit: fork-audit R/C/T diff-filter coverage + plumbing-vs-porcelain note (2026-04-29 round-10 Amara). NOTE: this comment is a single-slot "latest paired edit" marker (not a paired-edit log). Per the round-10 Amara framing the slot semantics are now explicit. -->
 
+- [**0/0/0 ACHIEVED + AceHack/Zeta protection-config dual-layer surprise — legacy deleted, rulesets canonical (Aaron decision, 2026-04-29T14:04:50Z)**](feedback_acehack_zeta_protection_config_dual_layer_legacy_deleted_rulesets_canonical_2026_04_29.md) — Hard-reset of `acehack/main` to LFG `621aae0...` succeeded after dual-layer protection surprise: AceHack/Zeta had BOTH legacy branch protection AND repository rulesets on `main`; both enforced independently; GitHub UI doesn't surface the dual-layer state. Aaron: *"I knew there were two but I was confused why."* Maintainer call: legacy DELETED, rulesets canonical going forward. Error-code mapping: GH013 = rulesets surface, GH006 = legacy surface. Old AceHack tip preserved at `archive/acehack-main-pre-000-reset-2026-04-29`.
+
 - [**Bare `main` is ambiguous — automation uses explicit refs (Amara, 2026-04-29)**](feedback_bare_main_ambiguity_automation_discipline_explicit_refs_required_amara_2026_04_29.md) — Generic multi-remote-repo automation rule: scripts use `refs/remotes/<remote>/<branch>` (or `refs/heads/<branch>`); bare branch names only for interactive humans. Hard-stop on fatal base-ref errors. Caught when bare `git checkout main` was hitting `fatal: matched multiple (2) remote tracking branches` and the loop continued past the failure with wrong downstream state.
 
 - [**Cold-readability addendum to Confucius-unfolding pattern (Aaron, 2026-04-29 addendum on 2026-04-25 file)**](feedback_confucius_unfolding_pattern_aaron_compresses_terse_rich_with_implication_claude_unfolds_into_operational_substrate_2026_04_25.md) — Operational addendum 2026-04-29 lands on the existing Confucius-unfolding canonical home (originally a 2026-04-25 file describing the Aaron-compresses + Claude-unfolds dynamic). New angle: when writing durable substrate, expand demonstrative pronouns / in-flight nicknames / implicit time-and-person references / recently-coined jargon inline — future-Claude reads on cold-start with zero shared context. Aaron's correction *"Confucius-unfold you have some existing skill or something for this — it has confucius in the name"* caught the over-eager substrate-creation failure mode (drafted a separate file under a longer name; consolidated into the existing canonical home). Composes with `agent-experience-engineer` skill (audit side) and the verbatim-preservation rule.

memory/feedback_acehack_zeta_protection_config_dual_layer_legacy_deleted_rulesets_canonical_2026_04_29.md

@@ -0,0 +1,101 @@
+---
+name: AceHack/Zeta protection config — legacy branch protection deleted, repository rulesets canonical (2026-04-29)
+description: During 0/0/0 hard-reset on 2026-04-29, AceHack/Zeta was discovered to have BOTH legacy branch protection (`/repos/{owner}/{repo}/branches/main/protection`) AND repository rulesets (`/repos/{owner}/{repo}/rulesets`) configured on `main`. The two layers enforce independently, and GitHub's UI does not surface that they're separate. Per maintainer call 2026-04-29 (Aaron), legacy protection was DELETED and rulesets are now the canonical protection surface for AceHack/Zeta. Future protection-config changes go through rulesets only.
+type: feedback
+---
+
+# AceHack/Zeta protection config — dual-layer surprise + decommission decision
+
+## What happened (2026-04-29T14:00–14:05Z)
+
+During the 0/0/0 hard-reset, `git push --force-with-lease` against AceHack/main was rejected with:
+
+```
+remote: error: GH013: Repository rule violations found for refs/heads/main.
+remote: - Cannot force-push to this branch
+```
+
+After disabling the only rulesets ruleset (id=15524390 "Default", `enforcement: disabled`) and retrying, the push was rejected AGAIN with a **different error code**:
+
+```
+remote: error: GH006: Protected branch update failed for refs/heads/main.
+remote: - Cannot force-push to this branch
+```
+
+That second rejection came from the **legacy branch protection layer** at `/repos/{owner}/{repo}/branches/main/protection` (with `allow_force_pushes: {enabled: false}`), which is a separate enforcement surface from the rulesets system.
+
+## Aaron's confirmation
+
+> *"GH006 (legacy branch protection). i might have had them both turned on"*
+> *"I knew there were two but I was confused why, the UI does not make it clear one is legacy, their UI is confusing but I do remember setting it twice."*
+
+So both layers had been configured at different times, both enforced together, and GitHub's UI does not visually surface that they coexist.
+
+## Maintainer decision (2026-04-29)
+
+> *"you could turn off both and leave the legacy off — when you turn back on, just turn back on the rulesets"*
+
+Executed:
+
+```bash
+# Delete legacy branch protection
+gh api -X DELETE repos/AceHack/Zeta/branches/main/protection
+# → "Branch not protected" (404)
+
+# Disable rulesets enforcement (--input - reads JSON body from stdin via heredoc)
+gh api -X PUT repos/AceHack/Zeta/rulesets/15524390 --input - <<'EOF'
+{"enforcement": "disabled"}
+EOF
+
+# The destructive force-push (now permitted)
+git push --force-with-lease=refs/heads/main:OLD_SHA \
+  acehack refs/remotes/origin/main:refs/heads/main
+
+# Re-enable rulesets enforcement (same heredoc pattern)
+gh api -X PUT repos/AceHack/Zeta/rulesets/15524390 --input - <<'EOF'
+{"enforcement": "active"}
+EOF
+```
+
+Note on `gh api --input`: it takes a FILE PATH, not inline JSON. Use `--input -` to read from stdin (then pipe / heredoc the JSON body in), or `--input path/to/file.json` for a file. Inline JSON via `--input '{...}'` is not supported syntax — `gh` would treat the JSON string as a filename and fail. Alternative: `-f key=value` for individual fields, or `-F` for typed fields.
+
+Final config: rulesets active, legacy gone. Single source of truth for AceHack/Zeta branch policy.
+
+## Error-code mapping (load-bearing for future debugging)
+
+| GitHub error code | Source | Surface |
+|---|---|---|
+| `GH013` | Rulesets ("Repository rules") | `/repos/{owner}/{repo}/rulesets` |
+| `GH006` | Classic / legacy branch protection | `/repos/{owner}/{repo}/branches/{branch}/protection` |
+
+If a push gets rejected with one error code, disabling that layer alone does NOT guarantee the push will succeed — the OTHER layer may also be enforcing. Always check both surfaces when diagnosing protection-related rejection.
+
+## How to detect both layers exist on a repo (script)
+
+```bash
+# Legacy branch protection
+gh api repos/{owner}/{repo}/branches/{branch}/protection 2>&1 | head -3
+# Returns full config OR "Branch not protected" (404)
+
+# Repository rulesets
+gh api repos/{owner}/{repo}/rulesets --jq '.[] | {id, name, enforcement, target}'
+# Returns array of rulesets with enforcement state
+
+# Status flag (high-level)
+gh api repos/{owner}/{repo}/branches/{branch} --jq '.protected'
+# true if EITHER layer is active; doesn't tell you which one
+```
+
+## Why this matters going forward
+
+1. **Operational diagnosis**: future force-push or branch-policy issues should check BOTH surfaces. Don't trust `branch.protected` flag alone.
+2. **Config drift**: future config changes must go through rulesets only; never re-create legacy branch protection on AceHack/Zeta.
+3. **Cross-org applicability**: this is a GitHub-wide UI confusion (not specific to AceHack). Other repos in Lucent-Financial-Group / etc. might have the same dual-layer config. Worth checking on cadence.
+4. **CLAUDE.md protocol verification**: CLAUDE.md says *"Force-push to AceHack main is part of the protocol"*. The rulesets `non_fast_forward` rule blocks this, which means **the rulesets config still doesn't match the documented protocol**. Either the protocol gets revised (no force-push, only sync via PR) or the ruleset's `non_fast_forward` rule needs a bypass-actor allowlist for the maintainer credential. Task #305-adjacent ("Set up acehack-first development workflow") is the home for that decision.
+
+## Composes with
+
+- `memory/feedback_destructive_git_op_5_pre_flight_disciplines_codex_gemini_2026_04_28.md` — pre-flight disciplines for destructive git ops (force-push needs `--force-with-lease=ref:exact-old-sha`)
+- `docs/active-trajectory.md` — 0/0/0 hard-reset gate spec + post-reset state
+- Task #305 (BACKLOG, pending) — set up acehack-first development workflow; protection-config protocol-vs-ruleset alignment goes here
+- `memory/feedback_aaron_visibility_constraint_no_changes_he_cant_see_2026_04_28.md` — Aaron's visibility constraint; this case satisfied it because Aaron was repo admin on AceHack/Zeta and could see the toggles in UI (even if confused by the dual-layer surface)