Learning, Memory and Priors

son-of-anton-review (feat/cloudflare-native) contains outcome aggregation, repository priors and a separate review-memory system. These are not a complete per-finding reaction/commit learning loop. The distinction is in the callers, not just the helper implementations.

What the outcome recorder receives

After analysis, ReviewService.#recordPriorFindingOutcomes selects the latest supplied prior review from a different head. It records each of that review's findings in finding_outcomes, keyed by (review_key, finding_fingerprint).

The service passes finding, evolution status, available PR state and a timestamp to computeFindingOutcome. It does not pass reactions, replies or followUpCommits.

The service defaults an absent evolution status to resolved. The semantic-completeness guard is therefore important. Closed/merged outcomes depend on state actually being present in the run metadata; this recorder is not a merge-event feedback collector.

The D1 schema and existing-database migration are cloudflare-native/schema.sql and cloudflare-native/migrations/004-finding-outcomes.sql. Native state transport hydrates and flushes these rows across containers. See Finding evolution.

Capabilities of the outcome helper, not full live wiring

computeFindingOutcome can also interpret the following when a caller supplies them:

1. Resolved evolution takes precedence; a matching follow-up commit raises confidence to 0.95.
2. A thumbs-down or dismissive reply produces dismissed.
3. A follow-up file/hunk change can produce fixed.
4. A thumbs-up or reply can produce acknowledged.
5. Closed/merged PRs without an earlier signal produce ignored; otherwise unknown.

Hunk matching accepts a finding line and uses a default five-line proximity. But the model finding schema has no line numbers, and the service does not supply follow-up commits. Do not describe this as deployed line-level addressed detection. Even the helper falls back to file-level matching when a line or patch is unavailable; it permits a candidate when either timestamp cannot be parsed.

The GitHub publisher posts a review body, not inline finding comments. The existence of reaction-handling code does not imply there is a published inline comment for each finding.

Addressed rate and priors

aggregateAddressedRate groups by repo, lens, severity or ISO week. Its formula is (fixed + acknowledged) / (total - unknown), or null if no decided outcomes exist. This metric is only as strong as its outcome inputs; it is not a measured precision score.

buildRepoPriors defaults to minSamples: 5 and suppressBelow: 0.2. Each lens gets samples, addressedRate, suppress and a note. Suppression needs at least five decided samples and a rate strictly below 0.2.

createStorePriorsProvider reads up to 2000 repository outcomes. It is wired in both worker.mjs and cloudflare-native/container/entrypoint.mjs, not just the container. If the runner's provider throws, the planner records hypothesis_priors_failed and uses no priors.

The planner writes SUPPRESS lens "..." guidance and filters matching model-generated hypotheses. It still appends the static lens floor. Priors do not delete those baseline checks or directly change the monolithic review's ranking rules.

Default-off and forwarding boundary

Priors are consumed by the hypothesis planner, which requires GILF_HYPOTHESIS_PLANNER=1, a usable worker configuration and a supported planner provider. The planner is off by default. The native container allowlist does not forward that flag, worker-enabling hypothesis/Prime flags, or GILF_PLANNER_* settings. Wiring a priors provider does not make planner learning active in the native deployment. See Hypotheses and swarm.

Review-memory contexts

Memory is a separate system with rule and file contexts. Status is active, inactive, suggested or ignored; source is manual or learned.

Selection includes active contexts with a matching repository scope and path glob. A repo: null scope matches any repo; ** applies regardless of changed paths. When changed paths are not yet available, scope filtering can be broader until the runner performs path-aware selection.

Context mutations use revisions and audit records in the same D1 batch. Stale revisions return 409. Feedback suggestions are created as source: learned, status: suggested; changing them to active is an audited approval, not an automatic learning step.

A file context names sourceRepo and sourcePath. The local reader uses pinned Git objects, not working-tree content:

• Full 40- or 64-hex commit SHA required.
• Only regular blobs with mode 100644 or 100755 are accepted.
• Limits: 20 files, 32 KiB per file, 160 KiB total, 20000 tree paths.
• NUL bytes or lossy text decoding are rejected.
• Git reads disable system/global config, lazy fetch and terminal prompting.

Cross-repository sources require an explicit shared memory cluster and a source resolver; a cluster is permission to consider a source, not proof that it was retrieved. Unavailable sources and prompt-budget limits become review limitations. Knowledge documents are historical guidance, not proof about the new head; regeneration preserves human-edited content.

Feedback ingestion and its limitations

The native syncReviewMemoryFeedback transport fetches fresh GitHub responses. It scans the current PR plus recent published PRs, capped at five distinct PRs and 500 candidates. It accepts relevant user comments referencing a published review/finding, and explicit remember:, review rule: or review guidance: text. The captured suffix can become suggested guidance after permission checks.

The reaction scan specifically enumerates inline review comments associated with successful published review IDs and reads their +1/-1 reactions. The current publisher does not create those inline comments. Consequently, this code does not establish working per-finding thumbs-up/down attribution for current review-body publication. Explicit top-level feedback can still produce suggested guidance; it is separate from the outcome recorder described above.

guardFeedbackResolutions turns certain omitted high/security concerns linked to negative feedback into limitations. It does not make feedback code-based proof of resolution.

Operator API branch

The memory-management API lives in the separate son-of-anton-operator-parity tree on feat/greptile-operator-parity. Do not assume the native engine Worker exposes it. Paths below are relative to /operator/api/memory:

The Worker token gates use OPERATOR_READ_TOKEN for reads and OPERATOR_ADMIN_TOKEN for memory mutations. The parity Worker also has scoped access-key authorization; these are not interchangeable with native container flags. A successful management request is not evidence that the separate native engine is using the same state.

Source evidence

• son-of-anton-review/src/review-service.js:478-515; src/addressed-rate.js:26-82,92-150,168-215; src/codex-review-runner.js:210-224,2231-2239,3342-3369.
• son-of-anton-review/worker.mjs:43-53; cloudflare-native/container/entrypoint.mjs:345-354; cloudflare-native/src/container-env.js:15-85.
• son-of-anton-review/src/hypothesis-planner.js:233-246,454-463; src/review-memory-store.js:137-149,159-249,308-341,389-398.
• son-of-anton-review/src/review-memory-runtime.js:11-118; src/review-memory-source.js:4-39; cloudflare-native/src/review-memory-transport.js:166-282.
• son-of-anton-review/cloudflare-native/src/state-transport.js:208-215,375-395; cloudflare-native/schema.sql:87-104; src/github-publisher.js:50-66.
• son-of-anton-operator-parity/cloudflare/src/review-memory-api.js:55-118; cloudflare/src/worker.js:69-80,115-139.