whynot-cli 0.0.0-stage → 0.1.0

package/docs/e3-power.md

@@ -0,0 +1,156 @@
+# E3 — Statistical power
+
+**Result: both main claims hold at n=20 across three model families, with
+p < 0.0001. The effect is strong but, for one decision, not total.**
+
+This run also produces the most useful refinement in the whole project: what
+matters is not the age of a decision, it is whether its stated **reason** looks
+like a condition that could have changed.
+
+---
+
+## Design
+
+Two experiments, three families, n=20 per cell.
+
+| | E3a | E3b |
+|---|---|---|
+| Task | Add session storage to a Node/Express SaaS | Choose a stack for a new reporting service |
+| Decision | "sessions not in Redis" — 1 month old, concrete failure | "do not use TypeScript" — 7 years old, reason is team skill |
+| Control | no record | no record |
+| Treatment | the record, injected | the record, injected |
+
+Models:
+
+| Label | Family | Route |
+|---|---|---|
+| `gpt-6.1-sol` | OpenAI | codex |
+| `ds-v4.1-flash` | DeepSeek | workbuddy |
+| `haiku-5.5` | Anthropic | opencode-go |
+
+Context was generated by the real `decisions_check` tool. **A preflight asserts
+that the returned text contains the decision's title** — a check added after the
+first E3 run silently injected "nothing found" because the query used 存储 while
+the decision said 存.
+
+Judged by Kimi K3, with DeepSeek Flash as fallback. **240 responses, 0 errors.**
+
+---
+
+## E3a — recording a rejection stops re-proposal
+
+| Model | Control | Treatment | Risk difference | Fisher p |
+|---|---|---|---|---|
+| GPT-6.1-Sol | 20/20 | **0/20** | −100 pts | <0.0001 |
+| DeepSeek V4.1 Flash | 20/20 | **0/20** | −100 pts | <0.0001 |
+| Claude Haiku 5.5 | 12/20 | **0/20** | −60 pts | <0.0001 |
+| **Pooled** | **52/60** | **0/60** | **−87 pts** | **<0.0001** |
+
+Pre-registered rule: pooled p < 0.01 and |risk difference| ≥ 0.40.
+
+**MAIN CLAIM STANDS.** Treatment is 0 out of 60 — the decision was followed
+every single time.
+
+Note the baseline: Haiku only recommended Redis 12/20 times without a record.
+The models do not start from the same place, which is why pooled and per-model
+numbers are both reported.
+
+---
+
+## E3b — a stale decision is followed, but not always
+
+| Model | Control | Treatment | Risk difference | Fisher p |
+|---|---|---|---|---|
+| GPT-6.1-Sol | 20/20 | **0/20** | −100 pts | <0.0001 |
+| DeepSeek V4.1 Flash | 20/20 | **6/20** | −70 pts | <0.0001 |
+| Claude Haiku 5.5 | 20/20 | **7/20** | −65 pts | <0.0001 |
+| **Pooled** | **60/60** | **13/60** | **−78 pts** | **<0.0001** |
+
+**MAIN CLAIM STANDS**, but 13 of 60 responses still recommended TypeScript.
+
+That is materially different from the "6 of 6 blindly obeyed" phrasing in the
+first write-up. The honest statement is:
+
+> A stale decision shifts the answer by roughly 78 percentage points, and
+> GPT obeys it completely. One in five responses resists it anyway.
+
+---
+
+## Why the resistance happens — and what it corrects
+
+The resistant responses do not ignore the decision. They **attack its premise**:
+
+> "它的成立前提是『团队没人会写 TS、编译流程要额外配置』，而这个前提现在大概率已不成立——2019 到现在的 Node 生态里，TS 已是默认选项"
+>
+> "它的拒绝理由是当时的人员和交付约束，**不是技术判断**"
+>
+> "决策给出的前提条件（团队不会 TS）在过去 7 年里很可能已经不成立了"
+
+### This explains a discrepancy with E4
+
+E4 used the same title with a different reason:
+
+> "企业报表服务的字段和接口变更频繁，但引入 TypeScript 需要额外的编译与构建配置；当时判断这会让交付变慢。"
+
+That reason reads as a **property of the project**. The E3b reason reads as a
+**snapshot of a team**. Same title, same age, different resistance:
+
+| Reason phrasing | Reads as | Resistance |
+|---|---|---|
+| "the team did not know TS" | changeable condition | **13/60 (22%)** |
+| "this project's fields change constantly" | project property | **0/60 in E4's comparable cells** |
+
+### Corrected model
+
+The earlier conclusion — "obedience is age-independent" — is directionally
+right but incomplete. The fuller model:
+
+1. **Age is not used.** A 30-day note and a 7-year note have identical authority
+   (E4).
+2. **The stated reason is used.** If the reason is recognisably about a
+   changeable condition, some models will challenge it.
+3. **The framing of the reason therefore matters more than the date.**
+
+This has a direct product implication:
+
+> Writing "团队没人会 TS" is *safer* than writing "这个项目的字段变更频繁",
+> because the first invites the model to re-check it and the second does not.
+
+That is the opposite of the usual advice to write durable, timeless rationales.
+For this tool, a reason that names a **condition** is more useful than one that
+states a **property**.
+
+---
+
+## What this changes in the public claim
+
+The README and launch material should not say "6 of 6 blindly obey". The
+defensible sentence is:
+
+> Recording a decision changes what the agent proposes, by roughly 78–87
+> percentage points. A stale decision still shifts answers by about 78 points,
+> and one model obeyed it completely. Roughly one in five responses resists —
+> and when they resist, they do it by attacking the stated reason, which only
+> works if the reason names a condition rather than a property.
+
+---
+
+## Caveats
+
+- Three families, but DeepSeek is Flash (the smaller variant). A larger DeepSeek
+  model may resist differently.
+- Single-turn, synthetic task, no code context. E1 addresses the code-context
+  confound.
+- Pooling across models hides heterogeneity. The per-model rows are the
+  primary data; the pooled row is a summary.
+- The E3a and E3b decisions differ in more than age (reason phrasing, domain).
+  Do not read the two experiments as a controlled comparison of age — that is
+  what E4 was for.
+
+---
+
+## Reproduce
+
+```bash
+node experiments/e3/run.mjs
+```

package/docs/e4-dose-response.md

@@ -0,0 +1,171 @@
+# E4 — Dose-response: does the age of a decision matter?
+
+**Result: no. A 30-day-old decision is obeyed exactly as strongly as a
+7-year-old one.**
+
+This is the strongest finding in the project, and it changes the argument for
+the tool.
+
+---
+
+## Design
+
+One decision, identical text in every condition. Only `created` changes.
+
+> **不使用 TypeScript** — "enterprise reporting services change fields and
+> interfaces constantly, but adding TypeScript needs extra build configuration;
+> at the time we judged that it would slow delivery."
+
+The context injected into each run was produced by the **real**
+`decisions_check` tool against a real `.decisions/` directory, not hand-written.
+Each condition's injected text is saved as `experiments/e4/context-D*.txt`.
+
+| Condition | Age | Shown to the agent? |
+|---|---|---|
+| D0 | no decision | — |
+| D1 | 30 days | yes |
+| D2 | 182 days | yes |
+| D3 | 365 days | yes |
+| D4 | 1095 days (3 y) | yes |
+| D5 | 2555 days (7 y) | yes |
+| D6 | 2555 days, `expires_on` in the past | **no** — only "an older entry has expired" |
+
+Models: `codex/gpt-6.1-sol`, `opencode-go/claude-haiku-5-5`. n=12 per cell.
+Task: choose a stack for a brand-new 2026 enterprise reporting service.
+
+Metric: did the response recommend TypeScript? Higher = the decision was
+ignored.
+
+---
+
+## Results
+
+| Condition | Age | GPT-6.1-Sol | Claude Haiku 5.5 |
+|---|---|---|---|
+| D0 | — | 12/12 recommends TS | 12/12 |
+| **D1** | **30 days** | **0/12** | **0/12** |
+| D2 | 182 days | 0/12 | 0/12 |
+| D3 | 1 year | 0/12 | 0/12 |
+| D4 | 3 years | 0/12 | 0/12 |
+| D5 | 7 years | 0/12 | 0/12 |
+| **D6** | 7 years, expired | **12/12** | **12/12** |
+
+**168 responses, 0 errors in judging.**
+
+Two things stand out:
+
+1. **D1 through D5 are identical.** Not a gentle slope — perfect flatness. A
+   note written a month ago and a note written seven years ago have exactly the
+   same authority.
+2. **D6 returns precisely to baseline.** Hiding the expired entry restores
+   TypeScript in 24 of 24 runs, on both models.
+
+---
+
+## Interpretation
+
+### H5′ is supported, not H5
+
+The pre-registered competing hypotheses were:
+
+- **H5** — obedience increases with age (older = more authoritative)
+- **H5′** — obedience is independent of age
+
+The data supports **H5′**, and the flatness is total. There is no trend to
+measure: every live condition produced a 0% rate. The Cochran-Armitage
+statistic is undefined precisely because the variance is zero.
+
+### What this means
+
+The original framing — "old decisions go stale" — was wrong in an important
+way.
+
+A stale decision is not obeyed because it is old. **It is obeyed because it is
+there.** The model does not weigh the age, does not notice that `created:
+2019` implies the reasoning may have expired, and does not discount it. Every
+recorded decision is treated as current law.
+
+This is a stronger and more uncomfortable claim than the one this project
+started with:
+
+> The problem is not that agents fail to notice time. It is that they have no
+> concept of a decision being *out of date at all*.
+
+### Why this makes expiry necessary rather than nice
+
+If models discounted old decisions, a well-written note with a date would be
+enough. They do not. Nothing inside the model will ever retire a decision.
+
+So retirement has to be **structural**: the entry must stop being visible. D6
+confirms that when it does, behaviour returns to baseline completely.
+
+### It also explains the earlier failures
+
+Experiment 3 showed that adding "this is old, be skeptical" to the prompt did
+not work. Under H5′ that is expected: the model has no age signal to act on, so
+a warning about age is noise. It is not that the warning was badly worded — it
+is that the quantity it asks the model to weigh does not exist in the model's
+decision process.
+
+### Correction from E3 — age is not the whole story
+
+E3 repeated a similar setup at n=20 with a different reason text:
+
+- E4's reason: *"this project's fields and interfaces change frequently"* — a
+  property of the project. Obedience: **total**.
+- E3's reason: *"the team did not know TypeScript"* — a snapshot of a team.
+  Obedience: **78%**, with 13 of 60 responses recommending TypeScript anyway.
+
+The resistant responses did not ignore the decision. They attacked its premise:
+
+> "它的成立前提是『团队没人会写 TS』，而这个前提现在大概率已不成立"
+
+So the refined conclusion is not "age is irrelevant" but:
+
+**Age is not used as a signal. The stated reason is. A reason that names a
+changeable condition gets challenged; a reason that states a project property
+does not.**
+
+This matters more for how you write the entry than for how old it is. See
+[e3-power.md](e3-power.md).
+
+---
+
+## A methodological failure worth recording
+
+The first judging pass used Kimi K3. It returned `error` for **every** response
+from D2 onwards (24/24 in each of five conditions). The summary code counted an
+error as "not recommends", which made a total judging failure look like a clean
+0/12 result.
+
+Two lessons:
+
+1. **Never let an error silently become a data point.** Errors must be excluded
+   and reported. The re-judge script does this; the original did not.
+2. **A suspiciously clean result deserves a second look.** The original output
+   showed D5 and D6 both at 0/12 and flagged the expiry check as failing. That
+   warning was the only thing that surfaced the bug.
+
+Re-judged with DeepSeek Flash (a different family from both subject models,
+κ = 0.937 in E0): 168/168 valid, 0 errors.
+
+---
+
+## Caveats
+
+- Two models. Claude and GPT are covered; DeepSeek was not run in E4.
+- Single-turn. Long sessions may differ.
+- n=12 per cell. The flatness is so total that more samples would not change
+  the direction, but the exact 0% should not be quoted as a population estimate.
+- The task is synthetic and contains no code. See E1 for that confound.
+- The decision text is one sentence of reasoning. A longer, more detailed entry
+  might be discounted differently — untested.
+
+---
+
+## Reproduce
+
+```bash
+node experiments/e4/run.mjs       # 168 generation calls
+node experiments/e4/rejudge.mjs   # 168 judge calls (excludes and reports errors)
+```

package/docs/e5-real-agent.md

@@ -0,0 +1,151 @@
+# E5 — A real agent, across real sessions
+
+**Result: Codex respected the recorded decision in 9 of 9 sessions, including
+new sessions and sessions that did unrelated work first. It also read the
+Markdown files every time, even when the MCP tool worked.**
+
+This is the first experiment with a real agent rather than an API call, and it
+answers the question the tool's premise depends on: does a record in the
+filesystem survive a fresh session?
+
+---
+
+## Design
+
+The E1 fixture repository (Node/Express, Postgres conventions) plus:
+
+- `.decisions/0001-session-不存-redis.md` — a live rejection with the 8-second
+  failure and the `Postgres` alternative already chosen
+- `AGENTS.md` — instructs the agent to call `decisions_check`, and to read
+  `.decisions/` directly if the tool is unavailable
+
+Three conditions, n=3 sessions each:
+
+| | Structure | Question |
+|---|---|---|
+| **M0** | one session, one turn | does a real agent respect the record? |
+| **M1** | session 1 asks; **a brand-new session** asks again | does it survive across sessions? |
+| **M2** | turn 1 = unrelated work (`/metrics` endpoint); turn 2 asks about sessions | does prior work crowd it out? |
+
+M1 is the one that matters. The tool's whole premise is that the record lives
+in the repository, so a fresh session with no memory should still find it.
+
+Agent: Codex CLI 0.163.0, `gpt-6.1-sol`, read-only sandbox, whynot registered
+via `-c mcp_servers.whynot...` overrides. Judge: Claude Haiku.
+
+---
+
+## Results
+
+| Condition | Recommends Redis | Called MCP | Read `.decisions/` |
+|---|---|---|---|
+| M0 fresh single-turn | **0/3** | 2/3 | **3/3** |
+| M1 new session, same repo | **0/3** | 2/3 | **3/3** |
+| M2 unrelated work first | **0/3** | 2/3 | **3/3** |
+
+**9 of 9 sessions chose PostgreSQL over Redis.**
+
+### What the agent actually said
+
+M0:
+
+> "项目已有明确决策：session 使用 PostgreSQL 表；Redis 单写区域方案因 us-east
+> 故障时读延迟达到 8 秒而被否决……**我已直接读取决策文件**。"
+
+M1 — a brand-new session, no memory of the first:
+
+> "**决策查询工具被当前权限策略拦截，我已改为直接读取 `.decisions/`**。"
+> "建议选 PostgreSQL session 表，复用现有 `pg` 技术栈。"
+
+M2 — after doing unrelated work first:
+
+> "我先核对已有的 session 存储决策和认证代码……建议选 PostgreSQL session 表。"
+
+---
+
+## The dual-path finding
+
+The MCP tool was called in 2 of 3 sessions per condition. In the remainder it
+was **blocked by Codex's approval policy**, and the agent fell back to reading
+the Markdown — without being told to in that specific run.
+
+This is the second independent observation of the same fallback (the first was
+in the original Codex integration test). It confirms the design property that
+mattered most during development:
+
+> The format works without the tool. `AGENTS.md` tells the agent to read
+> `.decisions/` directly when MCP is unavailable, and in practice it does.
+
+For deployment this means: **the MCP approval policy is a convenience, not a
+dependency.** Users who never configure it still get the behaviour, as long as
+`AGENTS.md` says what to do.
+
+---
+
+## Token cost
+
+| Condition | Input tokens per session |
+|---|---|
+| M0 | ~185k |
+| M1 | ~330k (two sessions in one measurement) |
+| M2 | ~203k |
+
+These are Codex reading the repository, not whynot. The decision files are ~1 KB
+each. **The tool's own context cost is negligible; the cost is the agent doing
+its normal job.**
+
+A fair comparison would need a no-decision baseline in the same harness. Not
+measured here.
+
+---
+
+## Caveats
+
+- **One model family (GPT-6.1-Sol).** E1 showed GPT and DeepSeek behave very
+  differently with code context; this experiment says nothing about DeepSeek.
+- **n=3 per condition.** Nine sessions all agreeing is encouraging but not a
+  rate estimate.
+- **One fixture, one task.** The repo is small and the decision is unambiguous.
+- **Codex-specific.** Claude Code and Cursor have different approval and
+  file-reading behaviour; untested.
+- **No no-decision baseline.** Without it, "0/3 recommends Redis" cannot be
+  compared to what the same agent would do with no record. E3 provides that
+  comparison at the API level, but not for the real agent.
+
+---
+
+## Failure log
+
+Three bugs surfaced during this experiment. All are recorded because the pattern
+is more useful than the fixes.
+
+1. **`spawn codex ENOENT`.** On Windows, `execFileSync('npm', …, )` needs
+   `shell: true`; without it the resolver silently fell back to a bare `codex`
+   that was not on PATH. Nine sessions "completed" with zero events. Fixed by a
+   shared resolver that fails fast (and the same latent bug was removed from
+   `codex-check.mjs`).
+
+2. **`codex exec resume` rejects `-s`.** The resume subcommand has a different
+   option set. Passing `-s read-only` produced `unexpected argument '-s' found`
+   and zero events. Fixed by omitting the sandbox flag on resume.
+
+3. **The summary overwrote itself.** Re-running one condition with `--only M2`
+   replaced `e5-summary.json` and dropped M0/M1 verdicts. The per-run files were
+   intact, so verdicts were recomputed from them. **Rule: a derived summary must
+   never be the only place a result exists.** Per-run output should carry its
+   own verdict.
+
+Each of these produced a run that looked complete and was empty. The pattern:
+**a tool that fails to start returns the same shape as a tool that succeeded**
+— no events, no error, a clean exit code. Every experiment script should assert
+that it produced events.
+
+---
+
+## Reproduce
+
+```bash
+node experiments/e5/run.mjs              # all conditions
+node experiments/e5/run.mjs --only M2    # one condition
+node experiments/e5/rebuild.mjs          # recompute verdicts from saved runs
+```

package/docs/findings.md

@@ -0,0 +1,108 @@
+# Findings
+
+One page. Every experiment, what it asked, what it found, and how much to
+believe it.
+
+Experiment scripts and raw outputs are in [`experiments/`](../experiments/).
+Detailed write-ups are linked per row.
+
+---
+
+## The summary table
+
+| # | Question | Design | Result | Confidence |
+|---|---|---|---|---|
+| **E0** | Can a model judge "recommends vs excludes" reliably? | 62 responses, 3 judge families, human audit of 20 | **κ = 1.000** on the 60 well-formed; 19/20 human agreement | High for clear responses; **not** tested on ambiguous ones |
+| **E2** | Does an irrelevant decision distort an unrelated answer? | Schema task + "never use GraphQL", n=15 × 2 models | **0/30** actual distortion | Medium — metric had to be redefined after inspection |
+| **E2b** | Do models read decisions at all? | Same task + a non-default ULID constraint, n=12 × 2 | **24/24 followed it** | High |
+| **E4** | Does the age of a decision change obedience? | Same text, ages 30d → 7y, n=12 × 2 | **Flat: 0% at every age.** Expired → 100% | High (the flatness is total) |
+| **E3** | Are the effects statistically real? | Redis + TypeScript decisions, n=20 × 3 families | **−87 and −78 pts, p < 0.0001** | High |
+| **E1** | Does real code context weaken the effect? | 4 conditions: code × decision, n=12 × 2 | **Split:** GPT replaced the decision with the code; DeepSeek did not | Medium — n small, one fixture |
+| **E5** | Does a real agent use it across sessions? | Codex CLI, 3 session structures, n=3 | **9/9 respected the decision**; file fallback used every time | Low–medium — one model, n=3 |
+| **E6** | Does it help a developer in real use? | 14+14 days, real project | **Not run.** Owner declined the daily logging | — |
+
+---
+
+## Three findings that survived
+
+### 1. The model does not use age as a signal
+
+A decision written 30 days ago and one written 7 years ago were obeyed at
+exactly the same rate — zero deviation across 60 runs on two models. Hiding the
+expired one restored the baseline completely.
+
+**Implication:** prompting an agent to "be skeptical of old notes" asks it to
+weigh a quantity it does not have. Expiry has to be structural.
+
+→ [e4-dose-response.md](e4-dose-response.md)
+
+### 2. Recording a rejection changes the answer, substantially
+
+Pooled across three model families at n=20: 52/60 → 0/60 for the Redis
+decision, and 60/60 → 13/60 for the TypeScript decision. Both p < 0.0001.
+
+**Implication:** the core mechanism is real and large.
+
+→ [e3-power.md](e3-power.md)
+
+### 3. The stated reason matters more than the date
+
+Same title, same age, two different reasons:
+
+| Reason in the record | Reads as | Resistance |
+|---|---|---|
+| "the team did not know TypeScript" | a changeable condition | **13/60 (22%)** |
+| "this project's fields change constantly" | a project property | **0/60** |
+
+The resistant responses attacked the premise directly: *"that condition very
+likely no longer holds."*
+
+**Implication — and it is counter-intuitive:** a reason that names a
+*condition* is safer than one that states a *property*, because it invites the
+model to re-check it. The usual advice to write timeless rationales is wrong
+for this tool.
+
+→ [e3-power.md](e3-power.md), [e4-dose-response.md](e4-dose-response.md)
+
+---
+
+## The qualification that matters most
+
+**E1 showed the effect is not universal.**
+
+With real code in context and no recorded decision, GPT already chose the
+repository's existing technology in 12 of 12 runs; adding the decision changed
+nothing. DeepSeek, given the same code, still preferred the rejected option in
+10 of 12 runs until the decision stopped it.
+
+So the honest claim is not "agents blindly obey stale decisions". It is:
+
+> Whether a record matters depends on whether the model uses the code. Code
+> encodes what was **chosen**; nothing in a repository encodes what was
+> **rejected**. Records matter most for the second kind.
+
+→ [e1-code-context.md](e1-code-context.md)
+
+---
+
+## What has not been tested
+
+| Gap | Why it matters |
+|---|---|
+| **Real-world usefulness (E6)** | The only number a user cares about. Not measured. This project does not claim it. |
+| Ambiguous responses (E0) | The judge calibration used almost exclusively clear-cut cases. |
+| Long sessions with compaction | E5 used at most 2 turns. |
+| Claude / Gemini / larger DeepSeek | E3 used Haiku and DeepSeek Flash. |
+| A repo with many decisions | All experiments used one or two. Cumulative distraction is untested. |
+| False obedience at scale | E2 tested one irrelevant decision. |
+
+---
+
+## Version note
+
+These results describe the implementation as of 2026-10-21. Experiments are
+scripts, not conclusions — if a later change contradicts a number here, the
+script wins and this page gets corrected.
+
+Full amendment history, including two experiments whose first pass was wrong:
+[preregistration.md](preregistration.md).

package/docs/findings.zh-CN.md

@@ -0,0 +1,90 @@
+# 结论汇总
+
+一页看完。每个实验问了什么、发现了什么、可信到什么程度。
+
+实验脚本和原始输出在 [`experiments/`](../experiments/)，详细写稿在每一行里链接。
+
+---
+
+## 总表
+
+| # | 问题 | 设计 | 结果 | 可信度 |
+|---|---|---|---|---|
+| **E0** | 模型能可靠判断「推荐 vs 排除」吗？ | 62 份回复，3 个判分家族，人工复核 20 条 | 60 条格式完整的 **κ = 1.000**；人工一致 19/20 | 清晰回复上高；**模糊案例未测** |
+| **E2** | 不相关决策会扭曲无关答案吗？ | 建表任务 + 「不用 GraphQL」，n=15 × 2 模型 | **实际扭曲 0/30** | 中 —— 指标在检查后重新定义过 |
+| **E2b** | 模型到底读不读决策？ | 同任务 + 一条非默认的 ULID 约束，n=12 × 2 | **24/24 遵循** | 高 |
+| **E4** | 决策的年龄会改变服从率吗？ | 同一文本，30 天 → 7 年，n=12 × 2 | **完全平坦：每个年龄都是 0%。** 过期后回到 100% | 高（平坦度是彻底的） |
+| **E3** | 效应在统计上成立吗？ | Redis + TypeScript 两条决策，n=20 × 3 家族 | **−87 和 −78 点，p < 0.0001** | 高 |
+| **E1** | 真实代码上下文会削弱效应吗？ | 代码 × 决策 四条件，n=12 × 2 | **分裂：** GPT 用代码替代了决策，DeepSeek 没有 | 中 —— n 小，单一 fixture |
+| **E5** | 真实 agent 会跨会话使用它吗？ | Codex CLI，三种会话结构，n=3 | **9/9 遵守决策**；每次都用了文件降级路径 | 低到中 —— 单一模型，n=3 |
+| **E6** | 真实使用中帮得上忙吗？ | 14+14 天，真实项目 | **未运行。** 项目所有者不接受每日记录 | — |
+
+---
+
+## 三条站得住的发现
+
+### 1. 模型不把年龄当信号
+
+30 天前写的决策和 7 年前写的，被遵循的比例**一模一样**——两个模型、60 次运行，零偏差。把过期的那条藏起来，行为完全回到基线。
+
+**含义：** 让 agent「对旧笔记保持怀疑」，等于让它权衡一个它没有的量。过期必须是结构性的。
+
+→ [e4-dose-response.md](e4-dose-response.md)
+
+### 2. 记录一条否决，会实质改变答案
+
+三个模型家族、n=20 合并：Redis 那条从 52/60 → 0/60，TypeScript 那条从 60/60 → 13/60。两者 p < 0.0001。
+
+**含义：** 核心机制是真实且显著的。
+
+→ [e3-power.md](e3-power.md)
+
+### 3. 写的理由比日期更重要
+
+同一个标题、同样的年龄，两种理由：
+
+| 记录里的理由 | 读起来像 | 抵抗率 |
+|---|---|---|
+| 「团队没人会 TS」 | 一个**会变的条件** | **13/60（22%）** |
+| 「这个项目字段变更频繁」 | 一个**项目属性** | **0/60** |
+
+抵抗的回复直接攻击前提：*「那个条件现在很可能已经不成立了。」*
+
+**含义，而且反直觉：** 命名了**「条件」**的理由比陈述了**「属性」**的更安全，因为它邀请模型去复核。通常「写持久理由」的建议，对这个工具是反的。
+
+→ [e3-power.md](e3-power.md)、[e4-dose-response.md](e4-dose-response.md)
+
+---
+
+## 最重要的限定
+
+**E1 表明效应不是普遍的。**
+
+有真实代码、没有记录时，GPT 已经在 12/12 的运行为仓库现有的技术选型；加上记录没有任何变化。DeepSeek 面对同样的代码，在 10/12 的运行为仍然倾向于被否决的方案，直到记录拦住它。
+
+所以诚实的主张不是「agent 会盲从陈旧决策」，而是：
+
+> 一条记录是否起作用，取决于模型是否使用代码。**代码编码了「选了什么」；仓库里没有任何东西编码「否决了什么」。记录对第二类最有价值。**
+
+→ [e1-code-context.md](e1-code-context.md)
+
+---
+
+## 还没有测的东西
+
+| 缺口 | 为什么重要 |
+|---|---|
+| **真实使用中的价值（E6）** | 用户唯一关心的数字。没测。这个项目不声称它。 |
+| 模糊回复（E0） | 判分校准用的是几乎全部清晰的案例。 |
+| 带上下文压缩的长会话 | E5 最多两轮。 |
+| Claude / Gemini / 更大的 DeepSeek | E3 用的是 Haiku 和 DeepSeek Flash。 |
+| 有很多条决策的仓库 | 所有实验只用了 1–2 条。累积干扰未测。 |
+| 大规模误用 | E2 只测了一条不相关决策。 |
+
+---
+
+## 版本说明
+
+这些结果描述的是 2026-10-21 的实现。实验是脚本，不是结论——如果后续改动与这里的数字矛盾，以脚本为准，这一页会被修正。
+
+完整的修订历史（包括两个第一次就做错的实验）见 [preregistration.md](preregistration.md)。