Rv/entire trunk - #2280
Open
Rohithvishnukumar wants to merge 13 commits into
Open
Conversation
BTW Buildathon 2026, Track 1 (Checkpoint-Native Developer Experience). This is
the required "initial understanding and intended architecture" checkpoint. No
product code yet - this commit records the problem framing, why Entire is
load-bearing, the planned architecture, and the decisions still open.
USER AND PROBLEM
Target user: a developer (or agent) returning to an agent-assisted codebase
after a break, a handoff, or a context loss, and anyone who has to judge
whether a branch actually did what it set out to do. Git shows *what* changed;
it does not preserve *why* a change was made, what was attempted and abandoned,
which assumptions were load-bearing, or which requirements are still open. That
reasoning is exactly what Entire Checkpoints capture on the
entire/checkpoints/v1 branch. The gap we are closing: reconstructing intent and
open risk today means re-reading a diff and guessing. We want the checkpoint
narrative to drive that instead, cross-checked against the real dependency graph.
WHY ENTIRE IS ESSENTIAL (not incidental)
- Checkpoints are the only source of stated intent, rejected options, and
unresolved risk per session. Remove them and the tool degrades to a plain
git-diff viewer - that is the "essential input" bar for Track 1.
- Entire Graph gives entity-level (function/type/route) relationships, so
"what else depends on what this session touched" and "did the code drift from
the plan" are answered semantically. A function moving file-to-file is not
drift; raw text diff would false-flag it, the graph will not.
- Dogfooding: our own build checkpoints from today ARE the dataset the tool
analyzes. At the noon curveball we run our own `entire resume` in a fresh
session to rebuild context - mandatory-workflow proof and demo proof at once.
PLANNED ARCHITECTURE
Shared core (build first, generic, takes a repo path - no hardcoded assumptions
about this repo's layout):
- CheckpointReader - parses entire/checkpoints/v1 into structured per-session
records: session id, timestamps, prompt/decision text, files touched, stated
intent. Exact on-disk/branch layout to be confirmed by an entire-graph
investigation of the checkpoint storage/parsing code (next step after this
commit).
- GraphClient - thin wrapper shelling out to `entire graph search|diff|impact`
and parsing their output; treats graph output as evidence to verify, not as
an oracle.
- DatabricksSync - pushes parsed checkpoint records into one Delta table
(Databricks Free Edition: one 2X-Small SQL warehouse, keep scope narrow).
Commands on top of the core:
- `entire resume` (must-have) - checkpoint narrative + Graph blast-radius for
touched files/symbols + one Databricks aggregate; renders to terminal and a
single self-contained HTML report.
- `entire drift` (must-have) - first-checkpoint plan vs. current code via
entity-level `entire graph diff`; lists unfinished / dropped requirements.
- `entire assess <commit-ish>` (stretch) - scopes Graph impact to one commit
and cross-references it against the nearest checkpoint's stated intent.
Databricks analytics layer: exactly one meaningful SQL query (requirement-
coverage % or file-churn/risk score) computed over the Delta table and read back
by resume/drift. Meaningful-use bar: removing Databricks must break the
trend/aggregate view, not just remove storage.
OPEN QUESTIONS (to decide during the build)
- CheckpointReader parsing target: confirm where session data actually lives
(branch tree layout, metadata.json vs full.jsonl transcript, sharding) before
designing the reader. Investigation is the immediate next step.
- Databricks SQL query: requirement-coverage % vs. file-churn/risk score - pick
whichever computes correctly and fastest from real checkpoint data.
- drift requirements baseline: a lightweight requirements.md kept alongside
checkpoints, or requirements parsed directly from the first checkpoint's
stated-intent text.
- Whether `entire assess` gets built at all - only if resume and drift are both
solid on real data first.
- HTML report scope - how much beyond a static render is worth the time.
Files in this commit:
- BUILDATHON_HANDOFF.md - full planning context, event rules, rubric, timeline.
- CLAUDE.md - new top section scoping this fork as a Buildathon build, not a
core-CLI contribution; upstream contributor docs apply only for tool-consumer
use of entire / entire graph.
- .entire/graph-agent.md, .entire/settings.json, AGENTS.md - entire-graph
plugin install / git-refs checkpoint backend setup.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Entire-Checkpoint: 01M1TH4V7EFETXQ0QGNR2E871W
Checkpoint Lens now has a working end-to-end path reading this repo's own real Entire Checkpoint data. This is the required "last stable state before the Noon Curveball" checkpoint. WHAT WORKS RIGHT NOW (verified against real data, not fixtures) entire lens handoff --repo . Resolves through the Entire CLI's kubectl-style external-command lookup (entire-lens on PATH -> `entire lens`), so it is invoked as a first-class Entire subcommand rather than a side script. It reads checkpoint 01M1TH4V7EFETXQ0QGNR2E871W out of refs/entire/checkpoints/, links it to commit 34c1528 via the Entire-Checkpoint trailer, and prints stated intent, per-session attribution, files touched and 27 classified decision items recovered verbatim from the transcript. ARCHITECTURE (deviation from milestone-1, recorded deliberately) Milestone 1 planned three top-level commands (resume/drift/assess) implemented in Go via direct import of checkpoint.Open() ("Tier B"). Both halves changed: - Language: Go is not installed on the build machine. Installing the toolchain and running `go mod download` against this repo before writing any product code was judged too expensive against a 15:00 hard deadline, and it would have made the post-noon iteration loop slow at exactly the moment iteration speed matters most. REJECTED in favour of Python invoked through Entire's own external-command mechanism, which keeps the tool a real `entire` subcommand living in this fork. - Shape: one `lens` noun with four verbs instead of three top-level verbs, so the four Track 1 use cases share one core and one schema rather than three parallel implementations. Modules: models.py (one schema shared by terminal, HTML and Databricks), reader.py (CheckpointReader over git plumbing), graph.py (GraphClient), report.py (rendering), cli.py (argparse entry). EVIDENCE THAT CHECKPOINT CONTEXT IS LOAD-BEARING The checkpoint's own files_touched records 2 files (AGENTS.md, CLAUDE.md) while the linked commit actually changed 5. The reader unions the two, so Graph blast-radius analysis sees .entire/settings.json and BUILDATHON_HANDOFF.md, which a checkpoint-only read would have missed and a git-only read could not have explained the intent of. This mismatch was predicted at milestone 1 and is now confirmed on real data. FAILURE HANDLED THIS SESSION Recovered decision text contains U+2192; the Windows console is cp1252, so the first `entire lens` run crashed with UnicodeEncodeError inside the CLI's own subprocess. Fixed by reconfiguring stdio to utf-8/replace: degrade the character, never the command. Checkpoint text is arbitrary agent-written Unicode and must be assumed hostile to the console encoding. UNRESOLVED WORK GOING INTO NOON - `entire lens drift` and `entire lens assess` are declared in the CLI's help and docstring but NOT implemented. handoff is the only working verb. - Databricks layer not started. Credentials confirmed available but not yet supplied. One Delta table + one aggregate query is the plan. - HTML report not started. - No tests yet. This is the largest quality risk on the board. - Graph blast-radius section is wired but has only been exercised with --no-graph; the JSON shape of `entire graph commit` is unverified, which is why _entity_names() tolerates several key spellings and why an unavailable graph renders as "unavailable", never as "no impact". OPEN RISKS - Only one checkpoint exists, so drift and any cross-session Databricks aggregate currently have a single data point. More checkpoints arrive as this build proceeds, which is the dogfooding path, but trend claims must stay honest about n. - The decision extractor is a transparent keyword classifier, chosen over an LLM call so output is verbatim and auditable. It will over-match: some recovered "decisions" are restatements of the prompt, visible in the current output. Precision work is deferred, not forgotten. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Entire-Checkpoint: 01M1TM6JKPX4MV0DV829FQ77GA
Bytecode artefacts were staged by a broad `git add tools/checkpoint_lens`. They are machine-specific and must not ship in the submission. Entire-Checkpoint: 01M1TM6ZCD0CP72K2HW6S945KY
…erly Verification before the noon stop caught a real defect in GraphClient: it invoked `entire graph commit --commit <sha> --format json`, but the plugin's interface is a POSITIONAL rev with `--json`. The wrong spelling does not fail loudly - the plugin exits 0 and prints "commit accepts at most one revision" to stdout, so a trusting caller would have rendered an empty blast-radius section as though the change had no dependents. That is exactly the "unavailable is not the same as no impact" failure the report layer was written to prevent, and it was live in our own client. Verified against the real payload rather than assumed. Actual shape is files[].changes[] carrying type / kind / name / dependents_count, so entity parsing moved into a dedicated module (entities.py) with an EntityChange record, and a shape-check that returns empty for anything unrecognised instead of guessing. This also buys the first genuinely useful risk signal: `dependents_count` combined with change type flags signature changes and removals that have callers - the shape that breaks things silently. Running it against our own HEAD reports .gitignore body_changed with 53 dependents. Graph evidence recorded (required action entireio#2, relationship/impact analysis): entire graph commit <sha> --repo . --json Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Entire-Checkpoint: 01M1TM9WCDTJJBYQNFEDCBJ04N
Completes the four Track 1 use cases over one shared core.
entire lens handoff hand off / resume after a break
entire lens drift review implementation against stated intent, and list
unfinished requirements
entire lens assess assess one change against its checkpoint's intent
entire lens sync push checkpoint records to Databricks, read aggregates
DATABRICKS IS LOAD-BEARING, NOT STORAGE
Three Delta tables (checkpoint_sessions / checkpoint_files /
checkpoint_decisions) and three aggregates, all live and verified against the
real workspace: 4 sessions, 29 file rows, 45 decision rows.
The aggregates are chosen so that they cannot be computed from any single
checkpoint, which is the "meaningful use" bar:
- open_items_trend: is unresolved context accumulating or being discharged
across the whole history? A blocker raised in checkpoint 1 and never
answered by checkpoint 4 is invisible to a single-checkpoint view.
- file_churn: hotspots are a property of the sequence of checkpoints.
Remove Databricks and the tool still runs, but both degrade to a single point
in time - and the CLI says so explicitly instead of showing one checkpoint's
numbers as a trend.
Sync is idempotent (DELETE by repo key, then batched inserts), so re-running
after new checkpoints never double-counts, and one workspace can host several
repos.
TWO MORE SILENT-FAILURE BUGS FOUND BY VERIFYING, NOT ASSUMING
Both had the same shape as the graph-commit defect fixed in the previous
commit - wrong flag spelling, no loud failure:
- graph search takes --top-k, not --limit. Every requirement was reporting
UNVERIFIED, which at a glance is indistinguishable from a query the graph
genuinely could not answer.
- search results are keyed on file_path with a snippet, not symbol/name, so
the hit extractor was scoring against nothing.
With both fixed, drift now correctly resolves the plan's own nouns to the code
that implements them: CheckpointReader -> reader.py, GraphClient -> graph.py,
DatabricksSync -> databricks.py.
REQUIREMENT EXTRACTION IS FILTERED
The baseline checkpoint's prompts include a whole planning document pasted in,
so naive extraction produced "Venue:", "Judging:" and "Submission deadline:"
as requirements. Now metadata labels and event logistics are rejected, and a
line must describe behaviour (action verb or code-shaped token) to count.
PERFORMANCE
18 sequential full-profile searches took 4m01s. Now concurrent (--jobs) and
defaulting to the fast profile: 58s for 18 requirements. --profile full is
still available where call-graph resolution matters.
TESTS: 40, all passing, stdlib unittest so a judge needs no pip install.
Coverage focuses on the dangerous cases: a failing graph must report ok=False
rather than an empty section; an unrecognised payload must return empty rather
than a guess; absent credentials must never read as configured; and the
files_touched union is pinned against the real checkpoints in this repo.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Entire-Checkpoint: 01M1TNJQEJTDEK7Y6MSGR5KBBQ
Required submission document. Records the problem and user, why Entire is essential (with the measured 2-vs-5 files_touched gap as evidence), the architecture, all three required Graph actions including the three silent interface defects verification caught, what each checkpoint proves, setup and test instructions, Databricks provenance and limits, and an honest known-limitations section. The Noon Curveball section is a placeholder until the constraint is revealed. Entire-Checkpoint: 01M1TNPW8FD7E6AV3JX3KJ5RKM
Running `assess` for the first time surfaced two defects, one in the data path and one in the display, that together made a recoverable intent look absent. DATA: not every checkpoint has a prompt.txt. Observed on real data - two of this repo's six checkpoints record "prompt": "" in the root manifest with no such file in the tree, because the commit was made mid-turn rather than at a prompt boundary. Intent then reported unavailable even though the transcript held the user's own words. Added first_user_message() as a third intent source, after the generated summary and prompt.txt: verbatim user text, same skip-short-commands rule as _pick_intent. DISPLAY: report.intent_provenance() mapped only two of the three sources and fell through to "unavailable" for anything else, so the newly recovered intent still rendered as missing - the exact opposite of the truth, and the more dangerous half of the bug, since the number was right and the label was wrong. Guarded by a test that enumerates every INTENT_* constant in models.py and asserts each has provenance text, so adding a fourth source cannot silently regress the label. An unknown source still degrades to "unavailable". Verified: `entire lens assess dda47c3` now reports intent recovered from the transcript and labels it as such. 42 tests passing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Entire-Checkpoint: 01M1TNVVBDT9YVNKF7G7P38WBN
…quality fixes
The product's central claim is that it preserves WHY a change happened. Reading
real output against our own checkpoints showed that section was mostly noise,
which discredits the claim regardless of how well the rest works. This commit
is the fix, and it is the most important one in the build.
THE CORE INSIGHT
A decision is something the agent CONCLUDED, not something the user ASKED FOR.
Previously the classifier scored any sentence containing a keyword, so the
agent quoting its own task back ("open questions we still need to decide",
"Commit everything with a substantive message") outscored genuine reasoning.
Three changes implement that distinction:
- EchoFilter drops sentences that repeat the prompt, verbatim or by >=60%
token overlap. Threshold is deliberately high: dropping a real decision is
worse than keeping a borderline one.
- Only assistant turns are mined. A user turn is a request.
- Questions are dropped. Asking something is not deciding it.
CLASSIFIER: MENTIONS ARE NOT CLAIMS
Substring matching on bare nouns was wrong in a way that produced confident
nonsense: "risk" matched the column name "file-churn/risk score", and
"abandoned" matched a sentence *defining* what checkpoints preserve. Both were
reported as findings about this project. Markers are now regexes requiring the
term to be predicated of the work ("we abandoned", "the risk is").
Over-correcting then lost most real content, because engineering prose states
decisions passively ("chosen over an LLM call", "idempotent, so re-running
never double-counts"). Added a `rationale` kind for causal prose - it is the
most abundant form the "why" actually takes, and it is now the largest
category. Net: 22 distinct high-quality items where the old code produced 27
mostly-noise ones.
Also fixed: hard-wrapped prose was split at newlines, producing entries that
began mid-clause; all-caps section headings classified as findings; markdown
emphasis leaked into output.
NEW: COMMIT MESSAGES AS A FIRST-CLASS SOURCE
A commit message is a deliberate, edited record of what was decided, unlike
transcript prose which is a by-product of working. Both are mined, both stay
verbatim, and every item now carries its source and confidence so a reader can
weigh them. Trailers and subject lines are excluded.
DATA QUALITY (Databricks)
- Decisions are attributed to the checkpoint where they FIRST appeared.
Entire stores the whole compacted session in every checkpoint, so counting
raw occurrences made one blocker look like it was raised again on every
commit and turned the unresolved-items trend into a monotonically
increasing line. This is what makes a falling trend mean what a reader
assumes it means.
- Build artefacts, vendored code and lockfiles are excluded from churn.
Our own committed-then-deleted __pycache__ sat at the top of a ranking
meant to point reviewers at risky source. Hotspots are now real files.
- The coverage headline counts rows in the decisions table rather than
SUM(decision_count) from sessions; the two disagreed because one is
deduplicated, so the headline could not be reproduced by querying the data.
- Found by a test: the dedupe key did not collapse whitespace, so
"backend!" and "backend" were two distinct decisions.
NEW: SELF-CONTAINED HTML REPORTS (--html)
One file, no server, no CDN, no external fonts - it has to open from a USB
stick when the network, the warehouse or the graph plugin is down, which is
exactly the demo-failure case the guide tells us to prepare for. Includes an
inline-SVG trend chart, hand-rolled rather than pulled from a charting CDN.
Anything uncomputable renders as an explicit "unavailable" panel, because a
silently missing section reads as a clean bill of health. Two checkpoints are
labelled as too few to be a trend rather than drawn as one.
SECURITY NOTE
Databricks credentials were pasted into this session. Verified they reached no
checkpoint: Entire's own redaction pipeline caught the token (11 REDACTED
markers), and a scan of every checkpoint ref, every tracked file, the whole git
history and the generated HTML found zero occurrences. The credentials file is
untracked and gitignored.
TESTS: 75 (was 42). The new module pins every noise case listed above against
the exact input that produced it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Entire-Checkpoint: 01M1TQ2SJR65VG107JGSEQ9MTA
Two additions that turn reporting into enforcement - the difference between a tool that describes drift and one that prevents it. DRIFT AS A RELEASE GATE (--fail-on-open) `entire lens drift --fail-on-open` exits non-zero when any requirement stated in the plan has no complete implementation evidence. That makes "did we build what we said we would build?" fail a pipeline the same way a red test does, and it is the capability that distinguishes this from a report generator. Verified: exit 1 with 5 of 6 requirements open. ADJUDICATED VERIFICATION (assess --verify) `entire lens assess <commit> --verify "<test cmd>"` runs the tests through `entire graph verify`, which reports WHICH TESTS CHANGED STATE - newly passing, newly failing, or already failing beforehand - rather than dumping runner output. That distinction is the point: a test that was already red is not evidence against the change under assessment. An assessment that says what changed but not whether it still works is half an answer. This is the other half, and it is what makes the curveball response provable rather than asserted. Baseline handling is explicit because the verifier requires one. When no baseline exists we record it and SAY SO: the run is then a state, not a delta, and presenting a first run as proof that nothing regressed would be a lie the tool tells confidently. Verified against the real plugin, including its honest report that unittest output is unparsed and the baseline is exit-code only. Both paths keep the existing failure discipline: a verifier that did not run is reported as "FAILED to run", never as a pass. 75 tests passing. Demo HTML reports committed under docs/demo/. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Entire-Checkpoint: 01M1TQF2VBAQ9ZKJJZDD6YGJJH
…ecisions Updates BUILDATHON.md for what the tool now does (drift as a release gate, assess --verify, self-contained HTML fallback) and documents the two data decisions that materially change the Databricks numbers: first-appearance attribution of decisions, and exclusion of build artefacts from churn. Also records that pasted Databricks credentials were verified absent from every checkpoint, tracked file, the git history and the generated HTML - Entire's own redaction caught the token. Entire-Checkpoint: 01M1TQGCCBZX7GPKX5JD9MN2ZT
Response to the Buildathon 2026 Track 1 noon curveball: PRIVACY BOUNDARY. WHAT THE CURVEBALL INVALIDATED - TWO ASSUMPTIONS, NOT ONE 1. TRUNCATION WAS TREATED AS DE-IDENTIFICATION. IT IS NOT. DatabricksSync capped free text at 800 characters (MAX_TEXT) and the module docstring offered that as the safeguard. A prompt cut at 800 characters is still 800 characters of the user's own words - a size cap wearing a privacy label. The live warehouse proved it: four of the eight sessions.intent rows were EXACTLY 800 characters, truncated mid-sentence and de-identified not at all, and they carried absolute local filesystem paths from this machine. decisions.text held a further 37 rows, 5,354 characters, of verbatim transcript and commit prose. 2. THE EARLIER CREDENTIAL CHECK WAS ASSUMED COMPLETE. IT WAS NOT. Checkpoints 01M1TQ2SJR65VG107JGSEQ9MTA (79743a3) and 01M1TQGCCBZX7GPKX5JD9MN2ZT (768bc92) both record that pasted Databricks credentials were verified absent from every checkpoint, tracked file, the git history and the generated HTML. That is true of the PAT - Entire's own redaction caught it. It is NOT true of the workspace URL, the org ID or the warehouse HTTP path, which sat unredacted in the stated intent of four checkpoints and were uploaded through the very intent column this commit removes. The infrastructure identifiers of the warehouse were being stored inside that warehouse. The check searched for the token and generalised its result to "credentials". The gap was in the generalisation, not in the search, which is the more dangerous kind: it produced a confident all-clear in a commit message, and that all-clear is what a reader would have trusted. GRAPH ANALYSIS BEFORE ANY EDIT `entire graph capabilities --json` reports every features_requiring_network_ access false, so the Graph plugin is local-only and not an egress path. `entire graph impact --symbol DatabricksSync._connect` returned the complete egress closure - 2 direct callers (sync for writes, _query for reads), 4 transitive, 1 callee (databricks.sql.connect) - proving databricks.py holds the only socket in the product. A source sweep agreed. Recorded because this project's own discipline demands it: `impact --symbol SessionRecord.to_row` reported ONLY a test caller. The real call site is in databricks.py inside `for s in rec.sessions`, which the Python resolver cannot type through the loop. Graph narrowed the search correctly and its caller list was incomplete. Evidence, not an oracle - the same lesson as the four silent graph-interface defects fixed earlier in this build. HOW THE DESIGN CHANGED The decisive finding was that no aggregate ever read either column. open_items_trend groups on kind, file_churn on file_path, and SQL_COVERAGE tests intent_source - never intent. Both raw-text columns were written and never queried, so removing them cost zero analytic capability. That is why this is a scalpel rather than a rewrite. - sessions.intent and decisions.text are gone. In their place: intent_len, intent_word_count, intent_digest, intent_redacted, and the same four for decisions plus confidence. - derive_signals() is the single chokepoint that turns text into those signals and discards the text. - assert_egress_safe() validates every outgoing row against EGRESS_COLUMNS immediately before the INSERT, so a column added later cannot quietly reintroduce prose. A test asserts the DDL and the spec cannot drift apart. - `sync --dry-run` prints the exact outgoing rows and connects to nothing. It calls the same build_rows() the real sync does, so it cannot describe a payload other than the one actually sent. Deliberate scope decision: file_path, branch, session_id, agent, model, linked_commit and token counts still leave the machine. They are checkpoint METADATA, not prompt or transcript content, and file_churn is unbuildable without file_path. Stated here so it can be revisited rather than discovered. WHY THE NEW RESULT IS SAFE Safety does not rest on the digest. A salted sha256 of short, low-entropy text is guessable, and derive_signals says so in its own docstring; the salt gives domain separation between repositories, nothing more. What makes this safe is that the plaintext never leaves the machine at all, and that the property is enforced by a guard at the wire rather than asserted in a comment. The full verbatim text is not lost - it stays in the local checkpoints, and handoff, drift and assess keep rendering it from git. Only the aggregate layer is de-identified. Data already sent was purged, not merely stopped. `sync --purge` dropped all three tables - DROP rather than DELETE, because DELETE leaves the columns in place and the rows reachable through Delta time travel - and recreated them on the text-free schema. Verified afterwards with DESCRIBE TABLE: no intent or text column exists in any of the three. Residual stated honestly: Unity Catalog keeps a 7-day UNDROP window, which is a workspace-admin action and outside what this CLI can reach. ONE COMPLETENESS SIGNAL INSTEAD OF FIVE The tool already reported degraded inputs in five places - a warnings block, a graph-unavailable line, a Databricks-unavailable line, an intent-provenance label - each true, each local to its section, NONE at the top, and none covering a missing transcript, an absent metadata.json, or content Entire had already redacted. A reader who stopped before the warnings block read a partial reconstruction as a complete one. completeness.py computes ONE verdict over all eight inputs, rendered first in the terminal, first in the HTML (above the stat grid, because those numbers are the most confident-looking thing on the page), and emitted as a machine-readable `completeness` object in every --json payload. - Redaction is a third state, not "available" and not "missing": the checkpoint is intact and some of what it described is gone. Run against this repo's own checkpoints, the tool now correctly reports PARTIAL. - "Not consulted" (--no-graph / --no-databricks) degrades the verdict rather than silently counting as healthy. - `drift --fail-on-open` now warns when it gates on partial context. A gate that goes green on context it could not fully read converts "we do not know" into "we checked". - render_decisions printed "(no decision context recovered from this transcript)" whether the transcript was read and held nothing, or was missing, or was fully redacted - identical output for three different truths, in the section this product's central claim rests on. Those are now three different sentences. Also fixed in the reader, which was silent about all of it: an absent metadata.json became an empty dict and rendered as a real session with zero turns and an unknown agent. It now warns, and the banner reports the figures as unknown rather than zero. TESTS AND PRESERVED BEHAVIOUR New: tools/checkpoint_lens/tests/test_privacy_boundary.py, 21 tests over a SYNTHETIC checkpoint fixture. It is labelled synthetic in the module docstring, in the class name (SyntheticCheckpointRepo) and here. No redacted fixture was supplied, so it was built: a real git repository with real refs/entire/checkpoints/** refs carrying four shapes - healthy, redacted (REDACTED markers), starved (no prompt.txt, no transcript), and no metadata.json at all. The redaction case does occur in this repo's genuine checkpoints; the missing-field cases do not, and a test that only runs where the defect happens to exist is not a test. EXISTING BEHAVIOUR WAS VERIFIED AS PRESERVED. The 75 tests that existed before the curveball were run as their own suite after the change and all 75 still pass, unchanged and unmodified. Total is now 96. handoff, drift, assess and sync were each re-run against this repository's real checkpoints, and the live aggregates still resolve after the purge and re-sync: 10 checkpoints, 42 decisions, 43 file rows. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Adds the reproducible evidence that the privacy fix landed on the live Databricks warehouse, not only in the code: DESCRIBE TABLE returns 27 / 4 / 10 columns across the three tables with no intent and no text column among them, and a session row now reports intent_len and a salted digest where 800 characters of a user prompt used to sit. Recorded because "we removed the column" and "the column is gone from the running warehouse" are different claims, and only the second one is checkable by a judge.
Completes the third required Entire Graph action against the submitted code rather than a description of it: entire graph diff --repo . --base 768bc92 --head HEAD --json 80 entity changes across 9 files - 66 added, 10 body_changed, 4 signature_changed. Graph named the four call contracts a reviewer must check out of roughly 860 changed lines, and confirmed nothing was removed: no existing caller lost a function. Each signature change is documented with the reason it was deliberate rather than collateral. Verified rather than trusted, and it mattered: the payload nests changes[] under files[], and a first parse against a top-level changes key returned 0 entity changes - which reads exactly like "this change touched nothing". Same silent-failure shape as the three graph-interface defects found before noon. Also records milestone 3 in the checkpoint table, and states plainly which milestones are carried by commit message rather than by a checkpoint ref. Entire-Checkpoint: 01M1TZ1WY5AED9MA0KG2RJC21Z
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.