Skip to content

feat(revisions): input digests, strict freshness and candidate planning (#1014) - #1063

Merged
jasonssdev merged 2 commits into
mainfrom
feat/1014-phase-b-p5b-service-plan
Sep 29, 2026
Merged

jasonssdev merged 2 commits into
mainfrom
feat/1014-phase-b-p5b-service-plan

Conversation

@jasonssdev

Copy link
Copy Markdown
Owner

Summary

PR 9 of the decision-revision-detector chain, which is Phase B slice P5b (stacked-to-main). It adds the planning half of src/openkos/application/revisions.py:

  • revision_input_digests: the digests a revision finding is keyed by, meaning each Decision's body plus every Source it reaches (sources-of: rows).
  • is_fresh: strict freshness. A stored finding is served only when every input digest, the judge prompt version and include_confidential all match the latest stored row. An unreadable input, or a missing or None digest, is never "unchanged".
  • plan_revisions: builds candidates with the pure plan_revision_candidates leaf over the stored vectors (EMBEDDING_SIMILARITY_THRESHOLD), then splits them into served (fresh findings from the P3 store, zero LLM calls) and to judge. The effects:
    • a Decision body edit re-judges only that Decision's pairs;
    • a Source event_date edit re-judges only the pairs reaching that Source;
    • a provenance path change through an intermediate concept makes the pair stale.

findings.db is probed before any connection is opened, so a read never creates the store. The whole-bundle text snapshot is extracted into _bundle_text_snapshot and shared with resolve_decision_dates, as a behavior-preserving refactor.

Size exception

size:exception. About 870 authored lines, mostly fixture-heavy tests that build a real vectors.db and findings.db. The owner authorized finishing Phase B autonomously, taking the recommended option; this is the same call as #1059 and #1061.

Related issue

Refs #1014

Type of change

  • feat — new feature

How was this tested?

  • Strict TDD: RED was observed (AttributeError) on all 12 new tests; the 11 P5a tests stayed green.
  • 6 mutations, each killed: a dropped one-side union; dropped sources-of ordinals; a weakened latest-row check; weakened strict digest equality; a disabled fresh flag; the is_fresh call removed from the serve/judge split.
  • One finding is worth keeping: a digest mutation applied at both write and read time is self-consistent and invisible to plan_revisions. Only the unit test that computes the sha256 independently catches it, which is why that test exists.
  • ruff check ., ruff format --check . and mypy . are clean; pytest --cov 6857 passed (97.02%); evals/run_self_tests.py 43 of 43.

Checklist

  • My commits follow Conventional Commits.
  • I added or updated tests for the change.
  • I updated docs where behavior, interfaces, or the knowledge model changed.
  • Lint, format, type check, and tests pass locally (ruff, mypy, pytest).
  • Output remains OKF-conformant and derived stores stay reconstructible from the bundle + sources.
  • The change is consistent with the project's guiding principles (local-first, provenance, freshness, human-in-the-loop).

… planning (#1014)

Extends the revisions service with revision_input_digests (design.md
Decision 2's per-pair input-digest table), is_fresh (the strict
freshness rule, never findings._is_stale's lenient None-means-unchanged
rule), and plan_revisions (the zero-LLM served/to_judge split over
read_decision_vectors and the Phase A plan_revision_candidates leaf).
@jasonssdev jasonssdev added the size:exception PR exceeds the 400-line review budget with maintainer-accepted exception label Sep 29, 2026
@jasonssdev
jasonssdev merged commit a6d74e8 into main Sep 29, 2026
9 checks passed
@jasonssdev
jasonssdev deleted the feat/1014-phase-b-p5b-service-plan branch September 29, 2026 03:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size:exception PR exceeds the 400-line review budget with maintainer-accepted exception

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant