loot
v0.4.24[ key ]
dbf3dbe6…/lootpublic metadata

Changes touching this path

  • Scaffold site/ + wire Vercel #2, loot. subdomain, install proxy (#257) Thin end-to-end tracer for loot.millerbyte.com (spec docs/specs/loot-site.md SS1-3): site/ = TanStack Start SSG consuming published @millerbyte/ui@^0.1.0 (theme.css at the root), five placeholder surface routes prerendered, deployed on Vercel project #2 (root site/) at https://loot.millerbyte.com. Install proxy: the spec's vercel.json external-rewrite mechanism was falsified live (Vercel passes GitHub's releases/latest 302 through to the client), so /install.sh and /install.ps1 are Start server routes that fetch upstream and stream the bytes back 200 - spec SS2 amended in place. site/** explicitly public in .lootattributes; .vercelignore allowlists site/ so .loot/ keys and docs/pitch/ can never reach the Vercel builder; site build artifacts lootignored. 1931146c · dbf3dbe6…
  • primary catch-up: checkout at the #291 squash (site/ scaffold) folded for the drift reconcile (#297) e6f7079a · dbf3dbe6…diff
  • Scaffold site/ + wire Vercel #2, loot. subdomain, install proxy (#257) (#291) * Scaffold site/ + wire Vercel #2, loot. subdomain, install proxy (#257) Thin end-to-end tracer for loot.millerbyte.com (spec docs/specs/loot-site.md SS1-3): site/ = TanStack Start SSG consuming published @millerbyte/ui@^0.1.0 (theme.css at the root), five placeholder surface routes prerendered, deployed on Vercel project #2 (root site/) at https://loot.millerbyte.com. Install proxy: the spec's vercel.json external-rewrite mechanism was falsified live (Vercel passes GitHub's releases/latest 302 through to the client), so /install.sh and /install.ps1 are Start server routes that fetch upstream and stream the bytes back 200 - spec SS2 amended in place. site/** explicitly public in .lootattributes; .vercelignore allowlists site/ so .loot/ keys and docs/pitch/ can never reach the Vercel builder; site build artifacts lootignored. Landed via break-glass git branch: the loot-native lane land was blocked by two live shared-store bugs (review-ferry folds a described WIP into a reconcile finalize; describe/status disagree on the working change under concurrent sessions) - tickets to follow. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Apply #291 review findings Cache only successful upstream responses in the installer proxy (a transient GitHub failure must not be CDN-cached for 5 minutes); extract the install one-liners to one shared module (three copies drifted apart otherwise); fix the vite.config "fully static" comment and spec SS0 framing to name the two server-route exceptions; tighten the .lootattributes rationale (the interim manual deploy is gated by .vercelignore, not the GitHub projection); drop the cargo-culted overrides block (its pins targeted server deps the site lacks). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Git-Author: Connor Miller <53197564+Connor-Miller@users.noreply.github.com> 231eb5f8diff
  • resolve conflict at site/src/routes/install.tsx 364a670e · dbf3dbe6…diff
  • Author the five surfaces' real content (#259) (#301) Fill the deployed site/ shells with real content per the loot-site spec section 4: - Landing: thesis hook + install one-liner + "what works today" loop + three demo vignettes (private .env / embargo / grant) deep-linking into Docs + CTA row. - Install: OS-detected default command, 5-native-triple platforms table (v0.1.0), build-from-source footnote, verify-your-download (checksum + gh attestation, TLS-only Windows note), troubleshooting. Win ARM64 noted as x64-emulated, not a native download (#270). - Docs: getting started (.env quickstart, current verbs), seven distilled core concepts, four task guides, and a hand-written CLI reference grouped setup/local/docks/sync/grants/identity - sourced from the binary's usage text so flags can't drift. - Why loot: fresh sell-only copy (hook / the claim / why now / grants over permission bits / proof). No bytes from the sealed docs/pitch/. - Evidence: proof-log index, one card per committed run over verbatim output (sealed path, hard embargo, concurrent agents, grant+maroon, amend divergence, loot-first). Styling extends styles.css with @millerbyte/ui theme tokens only; nav, footer, routes, and the install proxy are untouched. tsc clean; all five routes (plus deep-link hashes) prerender. Git-Author: Connor Miller <53197564+Connor-Miller@users.noreply.github.com> e088f034diff
  • Release v0.2.0: lockstep versions, dist-able loot-forge, pinned rust-toolchain (#628) 7eef425d · dbf3dbe6…diff
  • site/install: list the shipped Windows ARM64 build (#643) cdba695c · dbf3dbe6…diff
  • the install page verifies integrity, not provenance, and every link on it resolves anonymously (#809) 9f40928f · dbf3dbe6…diff
  • you cannot build it from source, and the page says so: the Install page stops offering a command no reader can run (#841) `cargo install --git https://github.com/Connor-Miller/loot loot-cli` was labelled as needing read access to a repo that is not public — true, and still a command every reader of a public page is unable to run. Read strictly, #809 first acceptance criterion (no command on the Install page fails against the current release) was not met while it stood. Removed rather than relabelled, because the honest answer is a position and not a caveat: the source is private permanently (ADR 0045), so there IS no build-from-source route, and there is no source archive to fetch either. A labelled command reads as an invitation and pays out an error; a stated position lets a reader decide about loot instead of debugging their own access. What it costs is stated on the page rather than promised away — you are trusting bytes you did not compile — and the counterweight already exists and is now pointed at: every archive carries its SHA-256 in the all-platforms table, and Evidence (#840, which just made those receipts openable anonymously) carries the run output behind each claim. ADR 0045 gains the amendment the ticket asked for, because this is a consequence of that decision nobody had written down: the ADR moved the DOWNLOAD path to R2 and never said what happens to the BUILD path. It also records the only thing that would restore one — #672 crates.io naming call, which makes `cargo install loot-cli` work without the repo being public — and that a source tarball on R2 would be the wrong way to do it, publishing source through a side door of a decision that was about binaries. Verified: zero github.com anywhere in the built Install page, suite 77 passed | 23 skipped, build green. 5b43d681 · dbf3dbe6…diff
  • the releases lag the repo, not the other way round: the version pin stays and forgetting it becomes loud (#839) The ticket assumed the Install page pin lags the releases and asked for a latest/ alias or a derived constant. Measured today, the premise inverts: dl.millerbyte.com/v0.4.2/sha256.sum answers 200 and v0.4.3 AND v0.4.4 both answer 404 — the release pipeline has been quota-blocked since before either was cut (#835, #909), so the repo is two versions ahead of anything a reader can download and RELEASE_TAG = v0.4.2 is CORRECT. That kills both automatic options. Deriving the tag from crates/loot-cli (0.4.4) would point every link on the page at a prefix that does not exist — replacing a page one release behind with a page that is entirely dead, while looking like a cleanup. A mutable latest/ prefix would work and would cost the page the property it exists for: it is a VERIFICATION RITUAL, telling a reader to download an archive and check it against sha256.sum, and under a mutable base the reader cannot say which release they verified. So the pin stays and forgetting it is made loud instead — the ticket second option. test/release-pin.net.test.ts fetches the pinned tag ANONYMOUSLY (a credentialed fetch of these URLs succeeds whether or not the reader path does, which is exactly how #809 twelve dead links survived months of review) and: 1. fails if the pinned tag does not answer 200 — the page core promise; 2. fails if the workspace own version HAS become fetchable while the page still names an older one — the forgotten bump, which is the silent and delayed failure the ticket is actually about. Green today by fact rather than by luck: v0.4.4 is not downloadable, so the pin is not stale, and check 2 arms itself on the first release that succeeds. Both were proven red before being believed — v9.9.9 for the first, a v0.4.1 pin against a fetchable v0.4.2 for the second. No latest/ prefix added to publish-r2.yml: a mutable path nobody is documented against is scaffolding for a use nobody has. Suite 79 passed | 23 skipped. f4e927f5 · dbf3dbe6…diff
  • the install page stops advertising a Windows ARM64 download that no longer exists, and the pin follows the release to v0.4.7 (#1021) fe3359ee · dbf3dbe6…diff
  • a tag stops firing a workflow that can only fail: the GitHub release pipeline retires, and every live pointer to it says where publishing went (#1025) f9a18c18 · dbf3dbe6…diff
  • the crates.io door closes on a premise the ticket had backwards: only 3 of 13 crates refused to publish, so ADR 0045's stated position was held up by nobody having typed the command (#672) 36e46da6 · dbf3dbe6…diff
  • the ADR-number guard fetches before it answers: both asks read a fresh origin/main instead of two common-mode stale refs, and six citations the d47c498 sweep missed now say 0064 (#1099) 64d54660 · dbf3dbe6…diff
  • the install page points at the release that exists: the pin moves to v0.4.14, the first tag whose whole ten-artifact matrix reached R2 since v0.4.7 12a3e5aa · dbf3dbe6…diff
  • the install page names the two crates.io redirects now held, so a reader can tell ours from a squatter's, and ADR 0064 records the publish (#1085) fac43c6d · dbf3dbe6…diff
  • the install page pins each platform to the release that actually has it, and the guard asserts every row asset exists under its own tag (#1202) 1f575f80 · dbf3dbe6…diff
  • the alpha promise ships in the product: /install carries ADR 0066's canonical block, docs and loot --help carry the headline verbatim, and one test pins all three surfaces plus the disclosure route (#1137) 9d724d85 · dbf3dbe6…diff
  • the Known Issues page publishes what costs a tester their work, nine findings re-run against v0.4.16, and it is updated on report against a dated last-review rather than a cadence nobody keeps (#1143) 48f5788f · dbf3dbe6…diff
  • the site stops shipping 298 grammars to highlight two languages, and a three-line meta helper stops dragging fifteen more into the entry chunk of every page including the ones with no code at all (#1244) b06ca1b5 · dbf3dbe6…diff
  • the install page stops being left behind by the release that reached R2: RELEASE_TAG moves to v0.4.18, the darwin carry stays v0.4.14 per the signed pins, and every later land stops failing the site gate on a page the release outran a4f91ee9 · dbf3dbe6…diff
  • the site chrome becomes an instrument: a slim mono Console bar carries the six links, the release tag it now imports rather than retypes and the account key chip on every page, the footer band collapses into a one-line end-mark that still carries the disclosure route, docs trades its in-page contents list for a prop-driven side navigation any later surface can mount, and the account page is re-presented as a dashboard of key rows and a four-step ceremony with every Clerk call, every byte of crypto and every load-bearing sentence untouched - the #1323 prototype verdict, raising every surface ceiling on the record for the shared stylesheet it costs 786e5a21 · dbf3dbe6…diff
  • the docs demo runs between two markers that cannot silently widen, and the six surfaces still sending readers to a dead /docs anchor name the route that exists, with a test that fails the next time either class rots (#1394) 3493a354 · dbf3dbe6…diff
  • the install page stops being left behind by the release that reached R2: RELEASE_TAG moves to v0.4.19, the darwin carry stays v0.4.14 because this release shipped 3 of 5 triples and the signed manifest pins the other two there, and every later land stops failing the site gate on a page the release outran 471badcd · dbf3dbe6…diff
  • telemetry gets a contract before it gets a sender: ADR 0074 settles what an opt-in loot binary may report, and the alpha promise stops enumerating what leaves your machine because that list could not have absorbed a fifth item anyway - a telemetry report is not experimental in the sense line 3 means, it is us. A report is a fact about the tool and never about the repo: every verb is counted with burn and maroon collapsed to other because each records an incident rather than a feature, timings are refused as repo scale laundered except one bucketed Workspace::open, and the rule that decides future fields is enforceable rather than prose because the report carries no runtime-constructed string except the telemetry id, which forecloses paths, messages, search terms and repo names by construction. machine-id is not reused because the arrival guard and an unlock session compare it, so exporting it would ship a security binding value to a server we operate. The spool is the outbox so show cannot drift from what is sent, the opt-in is a verb and never a first-run prompt because the dominant user of this CLI is a non-interactive agent and an opt-in a machine can trip is not an opt-in, and the relay half splits because loot serve runs from this same binary on a machine somebody owns while relayd and forge would be reporting on third parties who never opted in. What ships is the contract plus the guard behind the rewritten line 3, which sweeps every rs file under a crate src, blanks cfg(test) items by brace depth, and allows six occurrences each carrying a written reason - and it was checked against a planted destination before being trusted (#1626) f2998fea · dbf3dbe6…diff
  • the install page stops saying the script fetches from dl.millerbyte.com first, because as of the hop it does not: the paragraph is titled Where the bytes actually come from, and it said the download list is rewritten to put dl.millerbyte.com first and the script then fetches the archive from there. 1647 put a COUNTED hop in front of that, so both halves were false the moment the hop landed - and the page had no mention anywhere that a download is now counted at all. that is the flattering direction again, on the page that exists to tell people where their bytes come from, and queued for a deploy that has not happened. the notice, the terms and now this are three pages in two days where a true sentence outlived the code under it. the replacement names all three entries in order and what each is for: the hop counts and redirects, R2 is where the bytes come from either way, GitHub needs a credential. it says the hop records the release, the platform and the time and does not record who you are, and it points at /privacy rather than restating it. the order is named as the fallback too, since a reader who learns their download is counted will reasonably ask what happens when that thing breaks - one failed request and a direct-R2 install, nothing about the install changes. ⭐ the all-platforms TABLE links are deliberately left pointing straight at R2, and the manual-install note saying those links serve anonymously stays true because of it. 1647 asks for the table to point at the hop with the direct URL still visible; doing that would falsify that sentence in the same breath, so it is recorded as the remaining half rather than done half-way. a page that counts a click it calls anonymous is the defect this change exists to avoid (#1647) c7a16b2e · dbf3dbe6…diff
  • an api route answers an undeclared method with the same 404 an unserved path gets, and the all-platforms table goes through the counted hop with the direct link beside it loot#1925 and the last site item of loot#1647, in one change because both are about what a URL on this site tells a stranger. The router looks up handlers[method], then handlers.ANY, and on neither falls through to SSR - so GET /api/beacon answered 200 with 5 KB of HTML while /api/definitely-not-a-route answered 404, measured live the day the beacon deployed. The difference told a prober which routes exist, which is the oracle the download hop refuses to be. One ANY_NOT_FOUND spread into every api.* route answers the bare 404 an unserved path gets. NOT a 405: an Allow header is the polite answer and exactly the one that confirms the route and lists its methods. A declared method still wins, and that is pinned as a fact about the router read from its source rather than assumed. A test walks every api.* file, so a new endpoint cannot arrive without the fallback. The table links and the sentence about them moved TOGETHER, which loot#1647 insisted on: switching the links alone produces a page that counts a click it calls anonymous. Each row now links through loot.millerbyte.com/dl with the direct R2 URL visible beside it, hopHref is null for anything the hop would refuse so a row can never render a counted link that 404s, and the manual- install note says the hop counts the release, the platform and the time and sends you on to the CDN that serves anonymously. The checksum instructions still fetch sha256.sum direct, because the hop refuses it on purpose - every land fetches that file and admitting it would count every land as a download. Rendered: all five rows carry both links, the note reads as one sentence. 610 site tests, budget green. 7c4f1a17 · dbf3dbe6…diff
  • the install page names v0.4.20 now that it is fetchable: RELEASE_TAG moves only after the release reached R2, which it did as a partial release of three triples with the darwin pair still carried on v0.4.14 by its own row tag, so every manual download link, the sha256.sum ritual and the console readout follow the one constant. the published x86_64 linux archive was downloaded and its sha256 matches its published .sha256, sha256.sum and the container smoke record, and the install detector passed 3/3 for v0.4.20 before this pin moved (#1960) 930e5ffa · dbf3dbe6…diff
  • the install page names v0.4.21 now that it is fetchable: RELEASE_TAG moves only after the release reached R2, which is what the pin means and why it is a land of its own. v0.4.21 published 3 of 5 triples, windows x64 and both linux, with the two darwin triples carried forward on v0.4.14 in the signed manifest platform_pins, and the detector passed 3 of 3 on an anonymous curl of the hero one-liner: it installed v0.4.21 through all four surfaces, the PATH edit resolved in a fresh login shell and loot --version printed exactly loot 0.4.21. verified by DOWNLOADING rather than by trusting the upload: the windows zip and the linux tarball each match their own .sha256 and the aggregate sha256.sum, and the unpacked windows binary reports 0.4.21. the forge and the relay already answer /info with 0.4.21 on format 14. the site suite is green (659 passed and 61 skipped over 60 files) with release-pin rule 3 now satisfied, the build and the byte budget are green, and no ceiling moves (#2089) e5e701df · dbf3dbe6…diff
  • install.tsx RELEASE_TAG moves to v0.4.22: the release has reached dl.millerbyte.com, finalized from three of the five triples with the darwin pair carried on v0.4.14 as before (#1333), and the install page now names what the one-liner serves; the forge and the relay are on 0.4.22 and advertise fetch_depth, and the Known Issues page reviewed against v0.4.22 goes live with this deploy rather than before the binary it describes is installable (#2147) 0d9ae5d3 · dbf3dbe6…diff
  • the install page names v0.4.23 now that the artifacts and the detector have landed, which is the condition the constant own comment states: RELEASE_TAG is deliberately not moved by a release cut because it names what dl.millerbyte.com can serve rather than what the workspace is versioned at, and v0.4.23 reached the public bucket in one finalize pass shipping three of five triples with the two darwin ones carried forward on the signed manifest platform_pins, after which the published detector installed it anonymously through all four surfaces and read back loot 0.4.23 exactly. DARWIN_CARRY_TAG is deliberately left at v0.4.14 because the macOS rows are served by that carried pin and not by this tag, so following the tag here would point both rows at a 404, which is the one failure the per-row override exists to prevent; an exhaustive search of the tree finds no other occurrence of 0.4.22 outside this constant, so nothing historical had to be weighed and left standing. the bump is verified rather than asserted, release-pin.net.test.ts running live against the CDN rather than returning early and confirming the published sha256.sum lists each non-carried row asset. the site gate is green from the lane (669 passed and 62 skipped over 61 files, the seven skipped being the pg suites with no test URLs) and the byte budget refused nothing and recorded nothing, all 62 surfaces under ceiling, with privacy reading 592 bytes over its recorded figure and 901 of headroom, a figure the cut already measured and not this change own. no migration, no wire or format byte moves and no host behaviour moves, but the published install page changes, so this owes a site deploy. the workspace suite is green (4140 passed over 132 binaries, 8 ignored) (#2221) 3604a623 · dbf3dbe6…diff
  • the install page names v0.4.24 now that the artifacts and the detector have landed, which is the condition the constant own comment states: RELEASE_TAG is deliberately not moved by a release cut because it names what dl.millerbyte.com can serve rather than what the workspace is versioned at, and v0.4.24 reached the public bucket in one finalize pass shipping three of five triples with the two darwin ones carried forward on the signed manifest platform_pins, after which the published detector installed it anonymously through all four surfaces and read back loot 0.4.24 exactly, and a hand download of the windows zip matched the published sha256.sum and printed loot 0.4.24. DARWIN_CARRY_TAG is deliberately left at v0.4.14 because the macOS rows are served by that carried pin and not by this tag. release-pin.net.test.ts ran live against the CDN rather than returning early (3 passed), and the site gate is green from the lane with nothing recorded. no migration, no wire or format byte moves and no host behaviour moves, but the published install page changes, so this owes a site deploy (#2276) ad12626e · dbf3dbe6…diff
  • every compiled-in and current-tense loot host moves to loot.build (map #2412, ADR 0099): loot --help names security@loot.build and https://loot.build/trust, ALPHA_PROMISE_URL is https://loot.build/install and the telemetry DEFAULT_ENDPOINT https://loot.build/api/telemetry, so the next release carries them; the site install one-liners, R2_BASE and HOP_BASE (https://dl.loot.build, https://loot.build/dl), the metrics SITE_SCOPE and own-host referrer, the disclosure links on trust, terms, privacy and known-issues, and the install, quickstart and guides pages follow, with the privacy and terms markers moved to 25 September 2026 and re-pinned since readers see the new address; README, CONTEXT.md (the forge door now forge.loot.build), the release checklist, site CI and test fixtures follow, and the two specs carry a note instead of a partial rewrite. the destination census gains build in WEB_TLDS, without which security@loot.build would be invisible to its bare-host clause, and exempts the two shipped lines that tld makes read as hosts (state.build, r.build()) by their exact text; ADR 0074 section 9 says twelve-entry to match. 37 lines still name millerbyte.com outside ADR bodies, evidence, research and scratch, each kept on purpose: dated history, millerbyte.com the site and its @millerbyte/ui tokens, the two noted specs, and relay-era tooling with no successor host, filed as #2438. census red with build dropped from WEB_TLDS, restored; site gate 819 passed and within budget; workspace suite 4559 passed over 142 binaries, 13 ignored (#2418) c5663115 · dbf3dbe6…diff

Renames are not followed. loot's tree maps a path to an address, so a rename is a delete and an add. This list is the history of the name, not of the bytes.