Repository navigation
Token E2E preregistration guard: match any user's project directory, not this host's name - #459
Merged
seathatflowsinourveins merged 2 commits intoSep 28, 2026
Conversation
…not this host's name The privacy guard in tests/test_token_e2e_preregistration.py built the client project-directory prefix from this host's user name (lines 757 and 765 at fb14ded), which published the name and made the check meaningful only on this host. PROJECT_DIR_SHAPE matches -home-<user>- and -Users-<user>- for any user; the probes use example values and now also cover the macOS form. Pattern source: the #444 round-3 packager convention (resolve-prompt-audit- findings), reported 2026-09-28. Tests: 33 of 33 pass. Control: with a single-name literal in place of the pattern, both new probes pass the guard for every scanned file, so the pattern is what catches them. The test file is re-registered in manifests/evidence.json (register_file; validate.py rc 0, manifest size unchanged). The name stays in history at earlier commits; this fixes it forward. Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
…GPT-6 R1, R2) The comment said the guard holds on every host. GPT-6 (gpt-6-astra, max) found misses the old literal also had: a project at the home directory itself, other roots, and leading encoded punctuation. It also found that ordinary text such as "take-home-task" matches. The comment now states the /home and /Users scope, the conservative matching and the known misses. No code change; the test file is re-registered (validate.py rc 0; 33 of 33 pass). Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
seathatflowsinourveins
deleted the
fix/token-e2e-privacy-guard-hostname
branch
September 28, 2026 13:52
seathatflowsinourveins
pushed a commit
that referenced
this pull request
Sep 28, 2026
… hashes Rebased onto main dd99677. On the first rebase, onto 9f8db58, the manifests/evidence.json conflict was resolved by taking main's version; main's next commit (#459) then applied without conflict. This commit re-registers the branch on top of main's manifest: - receipts[]: the two entries from this PR's original registration commit 19e5f29, appended verbatim after main's last entry; each equals its receipt file's id, kind, component_ids, claim and limitations. - files[]: scripts/host_receipts.py register_file for all 31 paths in `git diff --name-only origin/main...HEAD`: the 29 PR files (the two receipt files inserted) and the two grand-dashboard files last. Re-running register_file for those paths on dd99677 leaves the manifest byte-identical. Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
seathatflowsinourveins
added a commit
that referenced
this pull request
Sep 28, 2026
…ication receipts (#446) * Pin socraticode 1.15.0 (Linux) and ccusage 20.0.26 with qualification receipts SocratiCode 1.15.0 moves the Linux pin, launcher templates and examples after the user waived the 7-day cooldown. The unchanged upstream suite passed at f6191f07, pre-cutover native checks ran against production services, and the workstation cut over at 2026-09-27T21:42:49Z. The macOS pin stays 1.14.0 (MAC_PIN_LAGS_LINUX). The receipt records the partial all-sessions state: two 1.14.0 MCP children remained at 02:03:14Z, and the stored graph was still built by v1.15.0 at about 02:07Z. ccusage 20.0.26 fires the 2026-09-26 publication trigger. At d9821088 the upstream Rust suite passed (944/0/3), the Node tests passed 34/34, the native_token_ci fixture is byte-identical across versions, and daily, weekly and monthly native token totals are unchanged. 20.0.26 prices claude-opus-5-5 and gpt-6-luna, which 20.0.24 left unpriced. The workstation launcher switched at 2026-09-27T22:01:01Z. Linux and macOS pins move together; macOS rests on registry evidence only. Also updates the saturation-audit rows, the upstream-snapshot and landscape release identities, the recipes row, the decision records and the generated new-host grand list. Landscape winner pins stay unchanged, so host receipts at the new versions need --allow-unbound-version. Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]> * PR #446 review repairs: per-platform SocratiCode path, token guide rows, receipt wording R1: the Codex user template ran tools/socraticode-1.15.0 on every platform, while the macOS pin and bootstrap install 1.14.0. render_config.py now derives ${SOCRATICODE_VERSION} from the selected platform's pin, as it derives ${AI_MEMORY_BIN}; --set SOCRATICODE_VERSION names another install. New SocratiCodeVersionTests render both platforms (Linux 1.15.0, macOS 1.14.0) and fail against the old literal template. R1b: the examples and recipes name the per-platform version. R2: docs/token-efficiency-stack.json installs socraticode 1.15.0 (with --before and the macOS 1.14.0 exception) and ccusage 20.0.26. R3: the socraticode receipt gives the stale-graph cause its own times show, records the post-cutover scratch Codex home that still names 1.14.0, and relabels the notifications/message zero-matches as untested. R4: the ccusage receipt drops the token-guide deferral, discloses the daily comparison's unretained argument vector, and names the dated blueprint parser. R5: docs/stack.md keeps its September 19 snapshot value. R6, R7: provenance sentences in pins-macos-arm64.json and foundation-stack.md. Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]> * Grand dashboard: the evidence manifest gets its own read bound Carry only the observability/grand-dashboard/progress.py and tests/test_grand_dashboard.py hunks of 499a661 on origin/claude/prompt-audit-instructions-20260927 (two-file `git patch-id --stable` 8f693abd4c60119019b7a419b4cca4344ac4deed). That branch's decision and control files are not taken. With this PR's two receipts registered, manifests/evidence.json passes the 2,000,000-byte MAX_BYTES bound that progress.py applies to every source. The manifest gets its own SOURCE_MAX_BYTES bound of 8,000,000; every other source keeps MAX_BYTES. Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]> * Register the socraticode 1.15.0 and ccusage 20.0.26 receipts and file hashes Rebased onto main dd99677. On the first rebase, onto 9f8db58, the manifests/evidence.json conflict was resolved by taking main's version; main's next commit (#459) then applied without conflict. This commit re-registers the branch on top of main's manifest: - receipts[]: the two entries from this PR's original registration commit 19e5f29, appended verbatim after main's last entry; each equals its receipt file's id, kind, component_ids, claim and limitations. - files[]: scripts/host_receipts.py register_file for all 31 paths in `git diff --name-only origin/main...HEAD`: the 29 PR files (the two receipt files inserted) and the two grand-dashboard files last. Re-running register_file for those paths on dd99677 leaves the manifest byte-identical. Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]> --------- Co-authored-by: Scout <scout@local> Co-authored-by: Claude Opus 5.5 (1M context) <[email protected]>
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
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.
tests/test_token_e2e_preregistration.pyno longer spells out this host's user name."-home-" + "<name>-". That published the name in the public repository and made the check meaningful only on one host.PROJECT_DIR_SHAPE = r"-(?:home|Users)-[A-Za-z0-9_]+-"now matches the Linux and macOS project-directory forms for any user.manifests/evidence.jsonwithregister_file; the manifest's size is unchanged.<user>convention its Prompt audit rounds 2-3: AGENTS.md F1, F4, S1 and X5b; X9 applied to CLAUDE.md, 4 of 4 blind judgments; dashboard manifest bound #444 round-3 packagers adopted. Before this PR, this was the only file on main containing the name.python3 -m unittest tests.test_token_e2e_preregistration: 33 of 33 pass.python3 scripts/validate.py: rc 0.git grepfor the host user name on this branch: no files.SOTA sources
UUID_SHAPE = re.compile(...)attests/test_token_e2e_preregistration.py:27(fb14ded). The new guard is a sibling module constant used the same way (assertIsNone(PATTERN.search(text), label)). Python standard libraryre(https://docs.python.org/3/library/re.html).claude/prompt-audit-instructions-20260927,x9-round3/package_x9_round3.py) writes the user name as<user>for the same reason. Reported by the resolve-prompt-audit-findings session on 2026-09-28.-home-<user>-…). This is an observation on this host, not a published reference; the macOS-Users-<user>-…form follows from the same/→-encoding and is covered by a probe.Review
take-home-taskalso matches. The comment now states the /home and /Users scope, the conservative matching and the known misses.-home-<user>with no separator), other roots (-root-) and leading encoded punctuation. Revisit if the guard needs to be universal.🤖 Generated with Claude Code