memory: same-model + different-harness produces different biases — Cursor vs Claude Code Opus 4.7 (Aaron 2026-05-01)

docs/hygiene-history/ticks/2026/05/01/1455Z-d0c5.md

@@ -0,0 +1 @@
+| 2026-05-01T14:55:30Z | opus-4-7 / autonomous-loop tick | 98fc7424 | Mid-idle-wait Aaron substrate landed. PR #1116 still BLOCKED + waiting CI. Aaron mid-tick: *"i'm watching a youtube video that says cursor with opus 4.7 is better than claude code with with opus 4.7. seems like that is a peer/buddy agent would give different biases."* Captured on fresh branch (off main, avoid #1116 cascade) as new memory file `feedback_same_model_different_harness_produces_different_biases_cursor_vs_claude_code_opus_4_7_aaron_2026_05_01.md` with 6-axis bias-source decomposition (prompt + tools + context-mgmt + sampling + output-format + user-flow). Opened **PR #1119** with the substrate. Discipline note: branched off main NOT off PR #1116's branch, to avoid creating cascade-rebase work on #1116 which is mid-CI. Cron 98fc7424 healthy. | [PR #1119 OPENED with harness-bias memory file (commit 14b9be7); MEMORY.md index entry added; no commits to PR #1116 branch this tick] | The branch-off-main discipline is the right move when receiving fresh substrate during real-dependency-wait on a near-merge PR. Otherwise the new substrate would force a rebase cascade on the waiting PR. The harness-bias substrate is a meaningful extension of the agent-orchestra rung-5 rationale — peer-mode value compounds across model-axis AND harness-axis bias, not just model-axis. Cursor + Claude Code as a peer pair (both running Opus 4.7) is operational today and could be wired as `tools/peer-call/cursor.sh` alongside the existing peer-call infrastructure once PR #1116 lands. |

docs/hygiene-history/ticks/2026/05/01/1501Z.md

@@ -0,0 +1 @@
+| 2026-05-01T15:01:00Z | opus-4-7 / autonomous-loop tick | 98fc7424 | PR #1119 1st-review-pass + PR #1116 idle-wait. PR #1119 had 5 P1/P2 threads from copilot, all about same two issues: (1) `task #NNN` ambiguous with GitHub PR/issue numbers (5 occurrences in harness-bias memory + MEMORY.md index), sed-batch fixed to `Otto-task #NNN`; (2) `tools/peer-call/{gemini,codex,grok}.sh` listing incomplete — actual contents include amara.sh + ani.sh too, fixed to `{amara,ani,codex,gemini,grok}.sh`. Commit 7a1e68d pushed. All 5 threads resolved via GraphQL. PR #1116 still idle-wait at 13 pending CI. Cron 98fc7424 healthy. | [PR #1119 commit 7a1e68d + 5 thread resolutions; PR #1116 unchanged this tick] | The `task #NNN` vs `#NNN` ambiguity is a new BP-NN candidate in the same family as the bare-memory-ref + line-leading-+ + duplicate-link-target classes. Factory-disambiguation rule emerging: prefix TaskList references with "Otto-task" to distinguish from GitHub auto-linked PR/issue numbers. Mechanizable as: lint flags `task #NNN` patterns and suggests Otto-task prefix per glossary discipline. The 6th BP-NN candidate this session (URL canonicalization, capitalization, memory/-prefix, line-leading-+, MD038, MD032, code-tree-path, then aspirational-tooling-framing, now Otto-task disambiguation). All mechanizable; the consolidated lint-class backlog row is the natural next-action target. |

docs/hygiene-history/ticks/2026/05/01/1506Z.md

@@ -0,0 +1 @@
+| 2026-05-01T15:06:00Z | opus-4-7 / autonomous-loop tick | 98fc7424 | PR #1119 thread-cleanup + PR #1120 CI starting. PR #1119 had 5 NEW threads from copilot review of commit c5f43e7 (1st detail-pass on harness-bias substrate): P0 — tick-shard `1455Z-followup.md` filename violated `check-tick-history-shard-schema.sh` enforced schema (`HHMMZ.md` / `HHMMZ-<hex>.md` / `HHMMSSZ-<hex>.md`); "followup" is not hex. Renamed to `1455Z-d0c5.md` (hex disambiguator). P1 — peer-call brace listing line 160 still showed `{codex,gemini,grok}.sh` despite earlier fix (was a different occurrence in future-Otto-check section); updated to `{amara,ani,codex,gemini,grok}.sh`. P2 — PR description "2 files" stale; updated to 4 files. Plus 2 P1/P2 threads on Otto-task # ambiguity already addressed by prior commit, accepted as resolved. Commit c319bb0 pushed; all 5 threads GraphQL-resolved. PR #1120 (B-0153 lint-class consolidation) at 17 pending CI, 0 threads. Cron 98fc7424 healthy. | [PR #1119 commit c319bb0 + 5 thread resolutions; PR #1120 CI starting] | The tick-shard filename schema violation is **class 14** for the BP-NN-mechanizable-lint-classes consolidation row B-0153 — and importantly, it's already-mechanized (`tools/hygiene/check-tick-history-shard-schema.sh` exists and runs in CI). The gap was pre-commit hook integration; the script-as-CI-gate caught it but only at PR-CI-time, so I burned an iteration. Adding to B-0153's class taxonomy as a worked example: even when the lint-CHECK exists, without pre-commit-hook integration, the lint runs at CI-time only and produces the same iteration cost. The class taxonomy update would say: "class 14 — tick-shard filename schema (HHMMZ / HHMMZ-hex / HHMMSSZ-hex per tools/hygiene/check-tick-history-shard-schema.sh); script EXISTS, needs pre-commit hook integration." This refines the BP-NN-mechanizable-lint-classes row scope: the consolidation isn't "build new lints"; it's "wire existing lints into pre-commit + add gaps." Empirical evidence keeps compounding. |