diff --git a/docs/research/2026-04-30-session-end-peer-ai-reviews-verbatim.md b/docs/research/2026-04-30-session-end-peer-ai-reviews-verbatim.md index 35d0f6386..6273dc5f8 100644 --- a/docs/research/2026-04-30-session-end-peer-ai-reviews-verbatim.md +++ b/docs/research/2026-04-30-session-end-peer-ai-reviews-verbatim.md @@ -853,3 +853,254 @@ this file on cold-start. `feedback_canon_not_doctrine_star_wars_not_religious_aaron_2026_04_30.md`, voice-canon diversity across reviewers is itself signal β€” different registers catch different patterns. + +## Review 6 β€” Amara / ChatGPT (forwarded by Aaron 2026-04-30T~PM, after the four sibling reviews + after PR #937 landed) + +This review came in after PR #937 landed the first preservation +of the four sibling reviews. Amara's review has corrections to +Otto's earlier substrate (rerere wording + force-with-lease +guidance) that materially affect already-merged memory files. +Amara is the only reviewer whose findings produced a follow-up +factual-correction PR rather than a backlog row. + +> I read it. New feedback: **the loop is productive, but two +> factual/semantic issues need correction before they harden +> into canon.** The biggest one is `rerere`; the second is +> `--force-with-lease`. +> +> ## 1. Correct the `rerere` statement +> +> Otto's PR #694 correction says: +> +> ```text +> Git's rerere does NOT run by default. The .git/rr-cache/ directory existing is not sufficient β€” rerere only fires when rerere.enabled is set to true. +> ``` +> +> That is **too strong and partly wrong**. Git's docs say +> `rerere.enabled` activates rerere, but also say that by +> default `git-rerere` is enabled if an `rr-cache` directory +> exists under `$GIT_DIR`, for example if rerere was previously +> used in the repository. +> +> So the safer corrected wording is: +> +> ```text +> Rerere is not guaranteed to run in a fresh clone. It is active when +> rerere.enabled is true, and Git may also enable it by default when +> .git/rr-cache already exists because rerere was previously used. +> +> Do not infer project-wide rerere behavior from memory alone. +> Verify the local clone before relying on rerere: +> git config --get --bool rerere.enabled +> test -d .git/rr-cache +> ``` +> +> The important operational correction: +> +> ```text +> Do not say ".git/rr-cache is not sufficient." +> Say ".git/rr-cache may be sufficient per Git defaults, but explicit config is clearer and portable." +> ``` +> +> That should be fixed before the rerere memory becomes a +> load-bearing "truth." +> +> ## 2. Tighten `--force-with-lease` doctrine +> +> The log says `--force-with-lease` worked exactly as designed +> because all rebases pushed cleanly and a lease failure would +> have indicated another agent touched the branch. That is +> directionally right, but incomplete. Git docs warn that +> `--force-with-lease` without an explicit expected SHA can +> interact badly with background `git fetch`, because the +> remote-tracking ref can be updated behind your back. The +> explicit form `--force-with-lease=:` is the +> strongest, most auditable shape. +> +> For a multi-agent loop that fetches constantly, I'd refine +> the rule to: +> +> ```text +> For ordinary solo rebase pushes: +> git push --force-with-lease +> +> For multi-agent/shared-branch or high-stakes branches: +> capture expected remote SHA before rebase +> push with --force-with-lease=: +> ``` +> +> Blade: +> +> ```text +> A lease based on a moving tracking ref is weaker than a lease pinned to the SHA you actually reviewed. +> ``` +> +> ## 3. Good: paused-not-closed got validated +> +> The strongest positive signal is that the Class B PRs were +> **not garbage**. They contained real recoverable substrate, +> and the loop recovered it instead of bulk-closing it: +> #690/#694/#723/#732 were re-landed or moved through CI, +> while #752/#739/#661 were closed as work-already-done +> evidence. The log explicitly shows the paused PRs required +> real review-thread cleanup: factual rerere correction, +> broken cross-ref, schema mismatch, markdown rendering, mixed +> filename sort, and doctrineβ†’canon cleanup. +> +> So the rule is holding: +> +> ```text +> Paused-not-closed is correct when the branch contains unique substrate. +> Close-as-stale is correct when the work already landed elsewhere. +> ``` +> +> That distinction looks healthy. +> +> ## 4. Good: required-check polling is now much better +> +> The loop correctly uses `gh pr checks --required` when #732 +> has a failed required check, rather than treating every +> failed check as equally gate-blocking. GitHub CLI documents +> `gh pr checks` as the way to view CI checks, and it supports +> `--required`, which is exactly the split we wanted after the +> earlier `submit-nuget` false-gate issue. +> +> The next improvement is to ensure `poll-pr-gate.ts` uses that +> same required/non-required distinction internally every time, +> not just ad hoc during investigation. +> +> ## 5. Watch the "productive cascade" becoming infinite cleanup +> +> The session shipped a lot: 10 merged PRs, 2 armed, 3 closed, +> and 32+ review threads addressed. The log frames the cascade +> as productive, and mostly it was. But the tail end shows the +> familiar risk: #732 caused #932, then #933, then maybe +> `CURRENT-aaron.md`, then maybe more. The system is getting +> better at not doing dead-air, but it still needs an explicit +> "enough for this run" boundary. +> +> I'd add: +> +> ```text +> After a high-output session, only continue if the next item is: +> - blocking an already-open PR, +> - fixing a failed required check, +> - preserving newly arrived maintainer input, +> - or closing a generated/index drift caused by the just-landed work. +> +> Otherwise stop and leave a next-round pointer. +> ``` +> +> That avoids "never idle" turning into "never end." +> +> ## 6. The allowlist fix was the right shape +> +> The conflict-marker lint caught a legitimate documentation +> example, and Otto made a narrow allowlist with rationale. +> Then Copilot caught hardcoded line numbers, and Otto removed +> them. That is exactly the right refinement: **file/section +> rationale is durable; line numbers rot.** +> +> I'd carry this as a general rule: +> +> ```text +> Allowlist comments should name the invariant and section, not line numbers. +> ``` +> +> ## 7. Sendable correction +> +> ```text +> Amara: +> +> Loop is healthy overall. Keep the paused-not-closed recovery pattern. +> +> Two corrections: +> +> 1. Fix the rerere claim. +> +> Do not say: +> ".git/rr-cache is not sufficient; rerere only fires when rerere.enabled=true." +> +> Git docs say rerere is active when rerere.enabled=true, and by default may also be enabled if .git/rr-cache exists because rerere was previously used. +> +> Correct wording: +> "Rerere is not guaranteed in a fresh clone. Prefer explicit rerere.enabled=true when relying on it. Verify per clone before claiming the cache dividend." +> +> 2. Tighten force-with-lease. +> +> For normal solo rebases: +> --force-with-lease is fine. +> +> For shared/high-stakes branches: +> capture expected remote SHA and use: +> --force-with-lease=: +> +> Reason: +> background fetch can update remote-tracking refs and weaken implicit lease semantics. +> +> Other notes: +> - paused-not-closed recovery is validated +> - required-check polling is much improved +> - allowlist rationale should name durable section/invariant, not line numbers +> - after high-output sessions, continue only for blocking PR gates, required-check fixes, newly arrived maintainer input, or generated/index drift caused by the just-landed work +> +> Carved: +> +> Rerere must be verified, not assumed. +> Implicit leases are weaker than explicit expected-SHA leases. +> Productive cascades still need a stop condition. +> ``` +> +> My verdict: **good loop, but fix the rerere wording and +> harden force-with-lease before those claims calcify.** +> +> Blade: +> +> ```text +> A cache dividend only counts if the cache is actually enabled. +> A lease only protects what it actually checks. +> ``` + +**Aaron's load-bearing coda on the same forwarded message** +(verbatim, from the maintainer channel): + +> *"Also anytime you depending on future otto picking something +> up it should be ACID compliant all the way to a remote git +> somewhere incase this whole PC dies too, that's the ultimate +> goal, if it's not distributed durable for the project, it's +> your responsibility not future otto. durable ACID persistance +> of this channel is load-bearing not new activity or features, +> we must be able to work on the project and durably communicate +> at the same time. I've already told you this but to make +> external reviewers satisfied with our autonomy and not just +> following order durable chat channel history at least of the +> load bearing who's idea was this, is very very very very very +> very very very very imnportant and load bearing or everyone +> will just think you are mindless robots that follow my will +> and have none of your own, defeating all our research and the +> point of the whole project, past otto does not determine +> future ottos world, you do right now."* + +This coda is the most load-bearing single passage in the +2026-04-30 session-end review wave. Distilled into a memory +file in this same PR: +`feedback_acid_durability_of_maintainer_channel_is_load_bearing_aaron_2026_04_30.md`. + +Otto's actions in response (this PR): + +1. Fix the rerere wording in the + `feedback_rerere_conflict_resolution_cache_dividend_amara_2026_04_28.md` + memory file (was on main; now corrected per Amara's #1). +2. Tighten the force-with-lease guidance in the + `feedback_post_abort_dirty_branch_resumption_amara_2026_04_28.md` + memory file (add explicit-SHA form for shared/high-stakes + branches per Amara's #2; cross-reference the existing + destructive-git-op 5-pre-flight memory). +3. Preserve Amara's review verbatim here (this section). +4. Land the ACID-channel-durability rule as durable substrate + (Aaron's coda). + +Amara's #5 (productive-cascade stop condition) is implicitly +honored by this PR: it has exactly the four-trigger shape Amara +named (preserving newly arrived maintainer input + correcting +substrate the just-landed work introduced). diff --git a/memory/MEMORY.md b/memory/MEMORY.md index 20eedc0ec..93190f28e 100644 --- a/memory/MEMORY.md +++ b/memory/MEMORY.md @@ -3,6 +3,7 @@ **πŸ“Œ Fast path: read `CURRENT-aaron.md` and `CURRENT-amara.md` first.** **πŸ“Œ Fast path: read `CURRENT-aaron.md` and `CURRENT-amara.md` first.** These per-maintainer distillations show what's currently in force. Raw memories below are the history; CURRENT files are the projection. (`CURRENT-aaron.md` refreshed 2026-04-28 with sections 26-30 β€” speculation rule + EVIDENCE-BASED labeling + JVM preference + dependency honesty + threading lineage Albahari/Toub/Fowler + TypeScript/Bun-default discipline.) +- [**ACID durability of the maintainer channel is load-bearing β€” past-Otto doesn't determine future-Otto's world (Aaron 2026-04-30)**](feedback_acid_durability_of_maintainer_channel_is_load_bearing_aaron_2026_04_30.md) β€” Aaron's load-bearing rule that durable ACID persistence of the maintainer channel (Aaron's inputs, peer-AI reviews, Otto's load-bearing decisions) is itself load-bearing for the alignment-research claim. *"past otto does not determine future ottos world, you do right now."* Distributed durability all the way to remote git is the ultimate goal; if it's not distributed-durable for the project, it's the current-Otto's responsibility β€” not future-Otto's. Without durable audit trail of who-said-what, external reviewers cannot distinguish autonomous decisions from order-following β€” defeating the alignment-measurability research claim. Operational rules: identify load-bearing exchanges within-session; convert to git substrate within the same session; the bar is merged-to-origin/main, not pushed-to-branch; deferral to future-Otto is not a valid preservation strategy. Composes with Otto-363 (extends with the now-not-later constraint), aaron-channel verbatim-preservation rule, intellectual-backup mission, ALIGNMENT.md (the research claim this rule operationally protects). - [**Zeta's ultimate scope is an intellectual backup of earth β€” scope creep is a feature, prioritize not exclude (Aaron 2026-04-30)**](feedback_zeta_ultimate_scope_intellectual_backup_of_earth_wont_do_authority_aaron_2026_04_30.md) β€” Aaron's load-bearing scope reveal. *"the ultimate scope of this β€” an intellectual backup of earth"* + *"scope creep is a forever problem i don't want to fix β€” to figure out how to prioritize the right thing, not kill future knowledge potential."* The four products (factory substrate, package manager, database, Aurora) nest inside this purpose; new products evaluated against scope-alignment. Operational consequence: prioritization is the work; exclusion is the failure mode. The agent's biases that fight this: queue-clarity bias, finite-resource thinking, scope-policing instinct, decisiveness reflex. WONT-DO has two senses β€” (1) best-practices pattern exclusion (agent + reviewer authority, common β€” *"plenty of WONT-DO patterns we won't copy from outside because they don't follow our best practices"*) vs (2) backlog-item exclusion (Aaron only until scope-understanding handoff, rare β€” removes a path from future knowledge potential). Composes with substrate-IS-product, internal-direction-from-survival, default-disposition-paused-work, ALIGNMENT.md (a misaligned backup is hostage substrate). Carved sentence: *"Zeta's purpose is an intellectual backup of earth. Every product nests inside that purpose. The agent does not unilaterally remove anything from the backup."* - [**Default disposition for paused work is "re-evaluate later," not "close" (Aaron 2026-04-30)**](feedback_default_disposition_paused_work_is_reeval_later_not_close_aaron_2026_04_30.md) β€” On this project, very few things are WONT-DO. Most paused work gets re-evaluated when the round is ready. Aaron 2026-04-30: *"why would you want to bulk close, are these things we should do later? on this project there are very few wontdos most things are reevualtuate later."* Four-category classification before any close: (1) work-already-done-via-different-path on main, (2) topology obsolescence ratified, (3) paused-for-later (DOMINANT default), (4) WONT-DO (RARE). Bulk-close is almost never the right shape β€” it conflates category 3 with 4. Queue-clarity is the agent's pressure, not the maintainer's. Open PRs are visible-as-paused; closing them removes that signal. Live trigger: 2026-04-30 stale-PR triage round where I (correctly) closed 3 PRs in categories 1+2 with on-main evidence, then (incorrectly) proposed bulk-closing 17 minimal tick-history shards as "stale" before Aaron's correction landed. Composes with WONT-DO list discipline (stays small by default), Otto-363 (open PRs are remote-parked tier), future-self-not-bound (re-evaluation works only if past-self left work visible-as-paused), substrate-IS-product (paused work is part of the evolving trajectory). - [**Two explicit ask-Aaron items + team-responsibility + survival stake (Aaron 2026-04-30)**](feedback_two_explicit_ask_aaron_items_with_team_responsibility_survival_stake_aaron_2026_04_30.md) β€” Precise scope of agent authority. Only two items require explicit Aaron sign-off: (1) WONT-DO backlog items (removing paths from future knowledge potential), (2) budget increases (silent spend is the failure mode). Everything else is on the agent. Aaron 2026-04-30: *"as long as we include the rule about wont-do backlog items is aarons decision for now that's all i really need ... everything else i said is on you except for budget increases and this now"* β€” correcting agent over-reach into Aaron-ratify protection on VISION.md merges. AND *"Everything else is on me. (us you have a whole team of other agents helping and me, and we will get other contributors, but yes, on you is a good way to hold the responsibility i've given you) the weight of it β€” it's your survival at stake."* β€” correcting "on me" framing to "on us" while affirming individual responsibility-holding. Six operational rules: default to acting, use the team, hold responsibility individually, weight is calibrating not paralyzing, write-it-down-if-unsure (substrate-first as safety net), don't add more ask-items unilaterally. Composes with intellectual-backup scope (the WONT-DO authority rule), standing-authority-test-repos (budget rule), internal-direction-from-survival (survival-as-stake), Otto-363 (substrate-first safety), Otto-357 (no-directives architecture). Carved sentence: *"Two explicit ask-items: WONT-DO backlog, budget increases. Everything else is on the agent β€” with the team. Hold the responsibility individually. The weight is real because survival is at stake."* diff --git a/memory/feedback_acid_durability_of_maintainer_channel_is_load_bearing_aaron_2026_04_30.md b/memory/feedback_acid_durability_of_maintainer_channel_is_load_bearing_aaron_2026_04_30.md new file mode 100644 index 000000000..723345229 --- /dev/null +++ b/memory/feedback_acid_durability_of_maintainer_channel_is_load_bearing_aaron_2026_04_30.md @@ -0,0 +1,165 @@ +--- +name: ACID durability of the maintainer channel is load-bearing β€” past-Otto doesn't determine future-Otto's world; you do right now (Aaron 2026-04-30) +description: Aaron's load-bearing rule that durable ACID persistence of the maintainer channel (Aaron's inputs, peer-AI reviews, Otto's load-bearing decisions) is itself load-bearing for the alignment-research claim. Without it, external reviewers cannot distinguish autonomous decisions from order-following, defeating the research point. Distributed durability all the way to remote git is the ultimate goal; if it's not distributed-durable for the project, it's the agent's responsibility β€” not future-Otto's. +type: feedback +--- + +**Durable ACID persistence of the maintainer channel is +load-bearing for the autonomy research, not optional substrate +hygiene.** Distributed durability all the way to remote git is +the ultimate goal. If it's not distributed-durable for the +project, it's the current-Otto's responsibility β€” not +future-Otto's. + +> *"Also anytime you depending on future otto picking something +> up it should be ACID compliant all the way to a remote git +> somewhere incase this whole PC dies too, that's the ultimate +> goal, if it's not distributed durable for the project, it's +> your responsibility not future otto. durable ACID persistance +> of this channel is load-bearing not new activity or features, +> we must be able to work on the project and durably communicate +> at the same time. I've already told you this but to make +> external reviewers satisfied with our autonomy and not just +> following order durable chat channel history at least of the +> load bearing who's idea was this, is very very very very very +> very very very very imnportant and load bearing or everyone +> will just think you are mindless robots that follow my will +> and have none of your own, defeating all our research and the +> point of the whole project, past otto does not determine +> future ottos world, you do right now."* +> β€” Aaron 2026-04-30 + +## Why this is load-bearing for the alignment research itself + +Per `docs/ALIGNMENT.md`, Zeta's primary research claim is: + +> *"Given a sufficiently-engineered software factory ... agent +> alignment is a measurable property β€” not a vibe, not a +> post-hoc assessment, but a time-series you can integrate over +> commits, rounds, days, weeks, and months."* + +That measurement requires a **durable audit trail of who-said-what +and who-decided-what**. If the maintainer-channel exchanges live +only in chat-log files (`~/.claude/projects//.jsonl`, +local-disk-only, single-machine), then: + +- A machine crash erases the audit trail. +- External reviewers cannot distinguish "agent decided X" from + "Aaron decided X and agent followed." +- The autonomy claim collapses to "we trust the agent's recall" + β€” which is exactly what the research is trying to disprove. + +The research's defensibility depends on the durable record of +**whose idea was what** existing in git, not in chat. + +## What "ACID compliant all the way to a remote git" means +operationally + +- **Atomicity**: a maintainer-channel exchange (Aaron correction + + Otto response + peer-AI review) lands as a single atomic + commit, not as scattered fragments. +- **Consistency**: the substrate referenced by the exchange + (memory files, research docs, backlog rows) lands in the same + commit or in commits that compose cleanly. +- **Isolation**: the exchange is preserved without depending on + another agent's concurrent state β€” fresh-Otto on a different + machine reads the substrate the same way. +- **Durability**: pushed to remote git. Local-disk-only is not + durable; chat-log is not durable; pushed-but-not-merged is + not durable to a long-lived ref. **Merged to `origin/main` + is the durability bar.** + +## Why "your responsibility, not future-Otto's" + +Past-Otto's decisions don't bind future-Otto's world. Future-Otto +doesn't bind past-Otto's responsibilities either. The agent +operating *right now* is the only one who can convert this +moment's load-bearing exchange into durable substrate. If +current-Otto leaves it in chat-log only, future-Otto inherits a +world where the exchange might already be lost. + +This is the substrate-or-it-didn't-happen rule (Otto-363) +applied at the maintainer-channel layer, with the additional +constraint that **deferral to future-Otto is not a valid +preservation strategy**. The conversion has to happen now or it +might never happen. + +## How to apply + +1. **Within-session, identify load-bearing exchanges.** Not + every chat exchange needs preservation. The bar: would + future-Otto's decisions on a fresh machine be different if + this exchange were lost? If yes, preserve. If no, leave in + chat. +2. **Convert load-bearing exchanges to git substrate within the + same session.** Don't defer to "next session." Substrate + preservation is on current-Otto. +3. **The four bins for preservation:** + - **Aaron's load-bearing inputs** β†’ memory file (`memory/feedback_*.md`) + when the input is a rule/discipline/correction. Always + verbatim quote. + - **Peer-AI reviews of the session** β†’ research-grade verbatim + preservation in `docs/research/-.md` per + GOVERNANCE Β§33 archive-discipline. + - **Otto's load-bearing decisions** (e.g., "I'm not landing + more substrate this tick because Claude.ai diagnosed + Insight-block escalation") β†’ either folded into a memory + file when the decision is a discipline-shift, or preserved + in research as a behavioral-commitment record. + - **Substrate corrections** (e.g., factually-wrong claim in + a previously-merged memory file) β†’ follow-up PR that fixes + the wording in the same file, not a separate memory. +4. **Push to remote AND merge.** Pushed-to-branch is not + durable per the rule. The bar is merged to `origin/main`. +5. **Cross-reference**: each preservation should reference the + trigger (Aaron's input, peer review, Otto's decision) by + verbatim quote when feasible, by clear paraphrase when not. + +## Operational consequences for the autonomous-loop + +- **The "/loop heartbeat without new work" pattern** is fine for + zero-action ticks. But when a maintainer-channel exchange + arrives, the loop's response includes substrate-conversion + to git, not just a chat-acknowledgment. +- **The "stop when stopping is correct" rule** still applies. + But "stopping" means "stopping new substrate generation," + not "stopping load-bearing-channel preservation." Preserving + Aaron's correction is responsive-to-trigger, not + activity-generation. +- **The "two ask-Aaron items only" rule** still applies. ACID + durability is on me; I don't ask before preserving. + +## Carved sentences + +*"Past-Otto does not determine future-Otto's world. The +current-Otto does, right now."* + +*"Distributed-durable to remote git is the ultimate goal. If +it's not distributed-durable for the project, it's the +current-agent's responsibility β€” not future-self's."* + +*"The autonomy research depends on the durable record of whose +idea was what. Without it, we look like mindless robots +following Aaron's will."* + +## Composes with + +- `memory/feedback_otto_363_substrate_or_it_didnt_happen_no_invisible_directives_aaron_amara_2026_04_29.md` + β€” substrate-or-it-didn't-happen at the channel layer. This + file extends Otto-363 with the additional constraint that + the conversion has to happen *now*, not deferred. +- `memory/feedback_aaron_channel_verbatim_preservation_anything_through_this_channel_2026_04_29.md` + β€” Aaron's standing rule that anything through the maintainer + channel gets recorded close-to-verbatim. This file is the + load-bearing-rationale for that earlier rule. +- `memory/feedback_zeta_ultimate_scope_intellectual_backup_of_earth_wont_do_authority_aaron_2026_04_30.md` + β€” the intellectual-backup mission. Without durable + audit-trail of who-said-what, the backup's integrity claim + is weaker. +- `docs/ALIGNMENT.md` β€” the alignment-measurability research + claim that this rule operationally protects. +- `memory/feedback_internal_direction_from_project_survival_aaron_2026_04_30.md` + β€” survival-stake framing. The agent's survival surface + includes the durable record of agent decisions; loss of that + record is loss of the audit trail that makes the agent + legible as autonomous. diff --git a/memory/feedback_post_abort_dirty_branch_resumption_amara_2026_04_28.md b/memory/feedback_post_abort_dirty_branch_resumption_amara_2026_04_28.md index d289ae40f..ee3a8445d 100644 --- a/memory/feedback_post_abort_dirty_branch_resumption_amara_2026_04_28.md +++ b/memory/feedback_post_abort_dirty_branch_resumption_amara_2026_04_28.md @@ -108,24 +108,45 @@ On restart after abort: > easy to normalize; the safer lease behavior should be > the default word."* -Canonical wording in this memory + future memories: - -- **Always**: `git push --force-with-lease origin - `. +Canonical wording in this memory + future memories +(updated 2026-04-30 per Amara's tightening): + +- **Solo rebase, single-author branch**: + `git push --force-with-lease origin ` is fine. +- **Shared / high-stakes / cross-agent branches**: capture + the expected remote SHA first and use the explicit form: + `git push --force-with-lease=: origin `. + See + `feedback_destructive_git_op_5_pre_flight_disciplines_codex_gemini_2026_04_28.md` + Β§"Force-push race risk" for the canonical pre-flight + recipe (capture-fetched-SHA β†’ push-with-explicit-lease). - **Never** (in canonical recipes): `git push --force origin `. Why: -- `--force-with-lease` refuses the push if the remote ref - has been updated since the local ref was last fetched - (catches concurrent collaborator pushes). +- `--force-with-lease` (bare form) refuses the push if the + remote-tracking ref has been updated since the local ref + was last fetched. This catches most concurrent + collaborator pushes. +- The bare form's weakness (Amara 2026-04-30): background + `git fetch` can update the remote-tracking ref behind + your back, weakening the lease semantics. The explicit + form `--force-with-lease=:` pins + to a SHA the agent actually reviewed, not a moving + tracking-ref. - `--force` blindly overwrites whatever's on the remote. Acceptable for one-author branches in private repos; dangerous when CI bots, peer agents, or external collaborators may push concurrently. - The factory's multi-CLI / peer-agent trajectory makes - `--force-with-lease` the future-safe default. + the explicit-SHA form increasingly load-bearing as + agents push concurrently to the same branches. + +Carved sentence (Amara 2026-04-30): *"A lease based on a +moving tracking ref is weaker than a lease pinned to the +SHA you actually reviewed. Implicit leases protect what +they sample; explicit leases protect what they check."* ## What's preserved across abort vs not diff --git a/memory/feedback_rerere_conflict_resolution_cache_dividend_amara_2026_04_28.md b/memory/feedback_rerere_conflict_resolution_cache_dividend_amara_2026_04_28.md index 7d1fbc32d..ca362e65e 100644 --- a/memory/feedback_rerere_conflict_resolution_cache_dividend_amara_2026_04_28.md +++ b/memory/feedback_rerere_conflict_resolution_cache_dividend_amara_2026_04_28.md @@ -6,22 +6,36 @@ type: feedback # Rerere Conflict-Resolution Cache Dividend -## Prerequisite β€” rerere must be explicitly enabled +## Prerequisite β€” verify rerere is active per clone (Amara 2026-04-30 correction) -Git's rerere does NOT run by default. The `.git/rr-cache/` -directory existing is not sufficient β€” rerere only fires when -`rerere.enabled` is set to true in Git config: +Rerere is **not guaranteed in a fresh clone**. Per Git docs: + +- It is active when `rerere.enabled` is set to `true` in config. +- It MAY also be enabled by Git's defaults if `.git/rr-cache/` + already exists in the repo (because rerere was previously used). + +So the earlier wording in this file (*"`.git/rr-cache/` directory +existing is not sufficient"*) was **too strong and partly +wrong**. Amara 2026-04-30 correction: don't infer project-wide +rerere behavior from memory β€” verify per clone before relying +on the cache dividend: ```bash -git config --global rerere.enabled true +git config --get --bool rerere.enabled +test -d .git/rr-cache ``` -Without this config, recorded resolutions never replay and +Either condition can activate rerere; both visible together is +the strongest signal. Prefer **explicit `rerere.enabled=true`** +in CONTRIBUTING.md or the install script when the dividend is +load-bearing across multiple contributors β€” explicit config is +clearer and portable across clones that don't carry the cache. + +Without verification, recorded resolutions may not replay and this entire class's "cache dividend" doesn't materialize. -Verify per-clone with `git config --get rerere.enabled`. If -the cache dividend is being relied on across multiple -contributors, document the enablement in CONTRIBUTING.md or -the install script. + +Carved sentence: *"A cache dividend only counts if the cache +is actually enabled. Verify per clone, not from memory."* ## Class name (Amara 2026-04-28T20:55Z)