docs(rfc): record recurring failures and gate their repair

[AlexStocks]

Which issue or RFC does this PR close?

Answers the design question raised in #1554 (feat: localize recurring failures to memory components and gate their repair). It does not close that issue: merging an RFC does not ship a capability, so #1554 stays open for the implementation discussion.

docs/en/rfcs/README.md asks contributors to validate a problem and direction through an issue before opening an RFC. #1554 is that issue, and it is linked as this RFC's optional Tracking Issue, matching how RFC 1489 links #1488. No separate tracking issue is created: the RFC process explicitly does not require one.

Rationale for this change

PowerContext records positive judgment well. ExperienceContent captures reusable judgment as situation / action / outcome / lesson, and Review validates it before publication. Nothing observes it after publication, and nothing can recognise that a failure has happened before.

The consolidation path makes this concrete. LLMExperienceCandidatePipeline.incubate deduplicates candidates by exact content equality plus source identity, and its seen set lives inside a single bounded window (EXPERIENCE_INCUBATION_WINDOW_LIMIT = 32). It never compares against earlier windows or against published revisions. The same failure observed twice therefore becomes two Experiences, and a re-worded description of one failure becomes two Experiences even inside one window. Recurrence is uncountable, so a lesson cannot be falsified — and a failure that keeps happening reads like accumulating knowledge.

RFC 0014 already lists "validated pitfalls" as preferred content and requires a durable entry to change a future agent's judgment, but it never defines what validated means. RFC 0051 lists "retirement, ranking, and usage attribution for Experience and Skill" as future work. This RFC supplies the usage-attribution half for the negative case, and keeps the boundaries those RFCs recorded: no automatic retirement or decay, and only explicit revision evidence can change a record.

What changes are included in this PR?

Adds one design document in both locales; no runtime, API, or persisted-format change.

• A machine-matchable identity. An optional failure block on ExperienceContent, whose signature is a recall_cue (the situation that should recall the record) plus an optional symptom. This is the only field that makes "this happened before" checkable.
• Repair-routing attribution. A required repair_surface naming the layer a fix must touch — experience_content, working_state, recall_policy, or acceptance_check — mapped onto PowerContext's own surfaces rather than copied from the reference implementation. It makes "the record is right but recall never fires it" an expressible diagnosis.
• An outcome ledger. selected / recurred / avoided per published revision, written only by the consolidation path. Selection is reconstructed from provenance that already exists (TaskOutcome.handoff_receipt_ref → Handoff revision → HandoffArtifactCitation[]), because RFC 0028 forbids writes and per-entry logging on the read path and RFC 1489 keeps model calls out of assembly.
• An evidence-gated admission rule. No failure record without a cited failing observation — a Task Outcome with status failed/blocked, or a TaskCheck with status failed/timed_out/unavailable. An unverifiable record is dropped rather than stored.
• Review-gated degradation. A recurrence streak marks a revision as needing review. A content-class failure proposes a revision candidate through the existing CandidateRepository; other classes propose nothing and surface in statistics. No automatic retirement, decay, or deactivation, and no artifact state field.
• A bounded read surface. A recurrence block on ScopeStatistics and a per-revision listing, returned by the existing statistics operation. No new MCP tool.
• Explicit non-goals in the document: no automatic attribution inference, no model calls added to prepare, no cross-Scope learning.

Two places deliberately do not copy the cited reference implementation: its automatic deactivation after 5 non-avoided hits (contradicts RFC 0051 and the absence of artifact state), and its mutable content-derived card id (contradicts immutable revisions).

Are there any user-facing changes?

No current behaviour changes. This is a design-only RFC.

It proposes one future public change: an optional failure object on ExperienceProposal in openapi/powercontext.yaml, which would require make api-generate followed by make contract-test. Because the field is optional, existing revisions remain load-compatible, and no schema_version is introduced — the Artifact families do not carry one today.

How was this change tested?

• make docs-test: passed. pnpm lint clean, and the static build finalized 712 pages, including the new RFC page in both locales. scripts/verify-static-export.ts reported: Verified 792 public pages and their internal links (106 HTTP API, 392 Python API, 74 RFC, 13 development).
• That build ran on the pre-renumbering revision, because docs/en/rfcs/README.md requires the RFC number to be assigned only after the pull request is open. The follow-up commit renamed both files from 0000_recurring_failure_repair.md to 1557_recurring_failure_repair.md and added the RFC PR header line; no link target or section of either document changed.
• Every relative RFC link in both documents was checked against the same locale directory; all 11 targets exist in docs/en/rfcs/ and docs/zh/rfcs/.
• The two repository hooks that apply to Markdown were checked directly: no trailing whitespace, and both files end with a newline.
• No Python, OpenAPI, or persisted-format file changed, so make test and ty check are unaffected by this PR.
• Every code reference cited in the document was read from source master at c2016666, the commit this branch is based on.

AI usage statement

WorkBuddy (Agent mode) using DeepSeek V4.1 Flash was used to inspect the current implementation and the related RFCs, verify every cited code reference against source master at c2016666, compare the design against the cited prior art, and draft the English and Chinese documents. The design decisions, the boundaries and the non-goals were reviewed interactively with the author.