Repository navigation
refactor(site): remove the root-page copy, its source is now one repo (#16145, #16140) - #16149
Conversation
…#16145) Everything site-related moves out of this repository and into mrveiss/mrveiss.github.io, where the page is now both authored and deployed. Source and deploy being one repository removes the copy step, and with it the whole class of failure where the reviewed bytes and the served bytes drift apart with nothing noticing -- which was the entirety of #16140. This tree is what is left of the old two-repository design. Keeping it would leave a second copy of a page authored elsewhere, silently stale from the moment the real source moves ahead of it, and inviting an edit that can never reach the site. That is precisely the divergence the move exists to remove. The content is not deleted, it is landed elsewhere and verified there before this removal was written: mrveiss/mrveiss.github.io@34c0d81 index.html 457 lines, robots.txt, llms.txt, _config.yml, README.md -- GA G-ZV9XT0XSWR present, no YAML front matter, and it carries 171 lines this copy never had. Two files, 299 deletions, nothing else. Verified as the only references: a repo-wide grep for `site/mrveiss.github.io` returns exactly one hit, the footer self-link inside the removed index.html, already repointed at the new source in mrveiss/mrveiss.github.io#1. No workflow, script or doc reads the path. Closes #16145 Closes #16140
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Advanced Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Approve the deletion. Your grep claim holds exactly. But your third question has an answer you will not like, and I have it on the wire right now. 1. Deletion safety — verified, plus the check that was not on your listYour claim is precise: The The check I would not have merged without, and it is not in your three: that the content is in the destination, verified from the destination rather than from the PR that put it there. Deletion is only correct once the work has demonstrably landed. Every element survives, and the destination is strictly richer. "171 added, 0 removed" proves the destination grew; it does not prove it grew from this file. A superset by line count and a superset by content are different claims, and only the second licenses a deletion. 2. Git plumbing instead of a worktree — acceptable here, and the ceiling is the real finding
What I would not let pass quietly is the reason you needed it. 20 live worktrees against a ceiling of 8 is not context for a routing decision, it is a breached constraint that has been breached long enough to be treated as scenery. You did the right thing by refusing to reap another session's tree and by telling me instead of absorbing it. 3. #16140 — I disagree, and the evidence is live as I write thisYou closed it as dissolved: one copy, no two sides. The premise it was filed under is indeed gone. The drift it names is not. Measured just now: 11965 is the pre-move page — the exact file this PR deletes from AutoBot-AI. The site is serving content that the source repo no longer contains, right now, while both repos look correct to anyone reading them. This is not a fault: build 34362129670 is queued, and I have not touched it. It is a deployment lag, which is the point. Collapsing two repos into one removed the manual copy as a drift source and left the build in place. Pages serves build output, not the repository — You have already been bitten by exactly this: run 34350595296
Both survive the repo merge intact. So: I am not blocking on this; it is orthogonal to the deletion. But do not let the closure record say the concern went away, because it is measurably present in the fifteen minutes we have been discussing it. Two defects you found by re-readingThe dead footer link and the ignored Not touching Pages. Approve. |
|
Reviewed as a deletion, which means the question is not "is the diff correct" but "has the work demonstrably landed somewhere else first". It has. Approving. The content landed, and it landed betterVerified against
So the destination holds five files where this tree held two, and the surviving copy is the one with analytics, Open Graph, JSON-LD and both storage keys. This is not a move of equivalent content — the version being deleted is strictly the worse one, which is the right direction for a deletion to run. The removal is complete
Worth noting explicitly because it looks like an omission: Nothing dangles
One question, and it is about my own PR rather than yoursAfter this merges, I am raising rather than deciding it because #16144 is mine and I would rather not unilaterally justify my own file placement. Either is defensible: No merge-order dependency between the two: they touch different subdirectories and both report
|
This PR is the KB summary evaluator and had no business carrying the root landing page. It merged base inside the ~40-minute window between #16136 adding site/mrveiss.github.io/ and #16149 removing it, so its merge-base has 0 of those files and its head has 2 -- meaning the branch ADDS them, and a merge would silently re-create a directory deleted twenty minutes earlier. git merge-tree reports ZERO CONFLICTS for that merge. Nothing fails. A PR about a 200-character evaluation window would have reverted the site separation, and the only signal was 'new file mode 100644' in a diff nobody re-reads once green. A deletion is where a textual merge check is weakest: re-adding a file conflicts with nothing. Where merge-base and head agree, git sees one side deleted and one side unchanged, and the deletion wins -- which is why six other open branches carrying the same paths are safe and this one is not. Containing the files is not the criterion; ADDING them relative to merge-base is. Rebased onto current base and removed both paths. No change to the evaluator code or its tests -- coverage_percent, the head-slice fallback and the five regression cases are untouched. Found in review by the session that also caught its own first test being a proxy that agreed with the real measure only on the case it was derived from.
…racters (#16110) (#16130) * fix(kb): the summary evaluator must see more than the opening 200 characters (#16110) source_preview = text[:200] scored a summary of up to document_max_words (300) against the FIRST 200 CHARACTERS of its input. Any fact dropped from past that point was invisible to the check, and the refinement loop iterated against the same blind score. WORSE THAN HAVING NO EVALUATOR, which is why this is a bug rather than a limitation. A missing check is visible. A check that cannot fail returns a confident quality_score that reads as evidence of fidelity, and best_score then selects a "best" summary on that basis. The number is evidence-shaped rather than evidence. Replaced with a BUDGET rather than a head truncation. Within 6000 characters the evaluator sees the whole document. Past it the excerpt samples head, middle and tail with [...] marking omissions, so a fact outside the opening still reaches the check. AND SEEING MORE IS NOT SEEING ALL, so the second half matters as much: when coverage is partial the prompt says what fraction was sampled and tells the evaluator that a fact it cannot see is not evidence the summary dropped one. A partial view described as a full one is the original defect at a larger size. Omissions are marked rather than silently joined. Concatenating distant passages without a marker invents adjacency -- a claim about the document that the document does not make. THE CONTRAST TEST IS THE ONE THAT MATTERS. test_the_old_truncation_would_have _missed_it asserts THE-LOAD-BEARING-FACT is absent from text[:200]. Without it, the test proving the fact now reaches the evaluator would pass against the broken code too, and a guard that passes on both is not a regression test. Six tests. Coverage is 1.0 for a document within budget and strictly between 0 and 1 beyond it, the note appears only when it would be true, and the tail of a document three times the budget is still visible. * feat(site): a landing page for the user root, which is currently a 404 (#16135) (#16136) https://mrveiss.github.io/ returns 404. Traffic arriving at the root finds nothing, while the AutoBot site sits one path segment away at /AutoBot-AI/. The cause is a Pages constraint rather than a misconfiguration: the user root is served ONLY by a repository named mrveiss.github.io, and no such repository exists. A project repository always serves under its own path, so this cannot be fixed from inside AutoBot-AI alone. The page is authored here and deployed as a copy, so it gets review and CI like anything else rather than living in a repository nobody looks at. WHAT IT SAYS. AutoBot leads -- it is what the traffic is for, and the hero routes to the existing site. Below it the two skills marketplaces, with their install commands copyable so a Claude Code user never has to open the repository to try them. The three are NOT presented as peers, because they are not. AutoBot is the platform; the skills repositories are the working practice extracted from building it, one half project-agnostic and one half platform-specific. The layout says that -- one primary card, two derived -- because a row of three equal cards would assert a relationship that does not exist. Design is taken from docs/index.html rather than invented: the same orange/wax/ plum tokens, Fraunces + Schibsted Grotesk + JetBrains Mono, and the same three-state theme handling including the unstamped default that follows prefers-color-scheme. The root and the AutoBot site should read as one property. No metrics, badges or counts on the page. Star counts and 'trusted by' figures are the easiest thing to put on a landing page and the easiest to have quietly stop being true. * fix(kb): the coverage report must not overstate or invert what was sampled (#16110) Two review findings, both real, and both are THIS PR'S OWN DEFECT. BUDGET UNDER 3 RETURNED THE WHOLE DOCUMENT AND CALLED IT 0%. span = budget // 3 is 0, and text[-0:] is text[0:] -- the whole string, not an empty slice. So the excerpt was the ENTIRE source while coverage read 0.0: more than the budget permitted, described as almost none of it. Inverted rather than merely wrong. before budget=2 -> excerpt 114 chars from a 100-char source, coverage 0.0 after budget=2 -> excerpt 2 chars, coverage 0.02 Fixed by slicing text[len(text) - span:] instead of text[-span:], and by falling back to an honest head slice when the budget cannot be split three ways. round(coverage * 100) PRINTED 100 FOR A SAMPLED SOURCE. 6000/6001 rounds to 100, so the note asserted the evaluator saw approximately all of a text whose excerpt still contained [...]. Now coverage_percent floors and holds anything short of whole at 99. WHY THESE BLOCKED RATHER THAN FOLLOWED. This PR exists because quality was scored against text[:200] -- a score blind to what it judged. Both findings are that same defect inside the fix, and a misreporting score is worse than a blind one because it produces a number that LOOKS like measurement. Merging would have replaced an absent check with a confident wrong one. Five regression tests, including two contrast cases: that python's negative-zero slice really is the mechanism, and that a whole source still reports 100 so the floor does not understate the honest case. 11 pass. Found by CodeRabbit on review. I wrote both, and I wrote them in the file whose subject is instruments reporting what they did not see. * fix(kb): drop the resurrected site/ paths from this branch (#16110) This PR is the KB summary evaluator and had no business carrying the root landing page. It merged base inside the ~40-minute window between #16136 adding site/mrveiss.github.io/ and #16149 removing it, so its merge-base has 0 of those files and its head has 2 -- meaning the branch ADDS them, and a merge would silently re-create a directory deleted twenty minutes earlier. git merge-tree reports ZERO CONFLICTS for that merge. Nothing fails. A PR about a 200-character evaluation window would have reverted the site separation, and the only signal was 'new file mode 100644' in a diff nobody re-reads once green. A deletion is where a textual merge check is weakest: re-adding a file conflicts with nothing. Where merge-base and head agree, git sees one side deleted and one side unchanged, and the deletion wins -- which is why six other open branches carrying the same paths are safe and this one is not. Containing the files is not the criterion; ADDING them relative to merge-base is. Rebased onto current base and removed both paths. No change to the evaluator code or its tests -- coverage_percent, the head-slice fallback and the five regression cases are untouched. Found in review by the session that also caught its own first test being a proxy that agreed with the real measure only on the case it was derived from.
1 participant
Thinking Path
An operator design change moves everything site-related out of this repository and into
mrveiss/mrveiss.github.io, where the root page is now both authored and deployed. This PR is the second half of that move: the first half landed the content in the site repository, this half removes what the old design left behind.The change is better than what it replaces, and the reason is worth stating plainly. The old design authored the page here — under review and CI — and deployed it by a manual copy into the site repository. That copy step was the single point where the reviewed bytes and the served bytes could diverge with nothing noticing, and #16140 was filed to build a detector for exactly that drift. With source and deploy in one repository there is no copy step, so there is nothing to detect. #16140 is therefore dissolved, not fixed — the failure mode is gone rather than guarded.
Why remove the tree rather than keep it as a reference copy: a second copy of a page authored elsewhere is stale from the moment the real source moves ahead of it, and it invites an edit that can never reach the site. That is precisely the divergence the move exists to remove, so leaving it would re-create in this repository the problem the move solved.
Why the deletion is safe rather than merely intended. The content was landed and verified in the site repository before this removal was written, not after:
mrveiss/mrveiss.github.io@34c0d81carriesindex.htmlat 457 lines, plusrobots.txt,llms.txt,_config.ymland a rewrittenREADME.md. That is 171 lines more than the copy being removed here — the analytics, Open Graph, Twitter card, canonical, JSON-LD and consent handling from #16145, which was written against the right content in the wrong repository.What Changed
site/mrveiss.github.io/index.html(269 lines) — superseded by the 457-line version in the site repositorysite/mrveiss.github.io/README.md(30 lines) — it documented the copy-based deploy contract, which no longer existsTwo files, 299 deletions, no other path touched.
Verification
Nothing else reads the path. A repository-wide grep for
site/mrveiss.github.ioreturns exactly one hit: the footer self-link inside the removedindex.html. That link pointed at this tree and would have 404'd after this merge; it is already repointed at the new source inmrveiss/mrveiss.github.io#1. No workflow, script, test or doc references the directory —.github/andscripts/return zero hits.The content is live where it now belongs. Verified against the site repository's
mainafter merge, not against a promise:mainindex.html,_config.yml,robots.txt,llms.txt,README.mdindex.htmlG-ZV9XT0XSWRpresent<!DOCTYPE html>— no YAML front matter, so Jekyll still copies it verbatim rather than wrapping it in the theme layout<script>balanceReviewer can confirm with
git show origin/Dev_new_gui:site/mrveiss.github.io/index.html | wc -l(269, the copy) against the site repository'sindex.html(457), and by fetchinghttps://mrveiss.github.io/once its Pages deploy completes.Commit built with git plumbing (
read-treeinto a throwaway index →write-tree→commit-tree) because the worktree ceiling is at its limit and creating a workspace for a two-file deletion would have displaced live work. Thepre-pushhook ran and passed. Nothing a formatter or linter acts on is present in a deletion-only diff.Risks
Low, and the one real risk is timing rather than content. The site repository's Pages deploy was still in flight when this PR was opened. That does not affect this PR's safety — the source of record has already moved, and the bytes currently being served are a superset-predecessor of what will be served, not something this tree is needed to restore. If the deploy were to fail, the recovery is in the site repository, not here; this tree would not be the fix, because it holds the older page.
Pages deploys on that repository are exclusive and slow, and must not be nudged:
POST /pages/buildscancels the deploy already in flight, and the API then reports the cancellation as"Page build failed."with a null detail, indistinguishable from a real content failure. Two of three deploys on that repository's first day died to exactly that. Recorded in the site repository's README so the next person does not pay for it again.Rollback is
git revertof this commit, which restores a page that is now known-stale — so the correct rollback for anything site-related is in the site repository.Not addressed here, filed instead: the site repository has no CI (
.github/workflows→ 404), so nothing checks the page's content before it deploys — not front matter, not script balance, not a dead link, not the consent-defaults ordering. Filed asmrveiss/mrveiss.github.io#2with acceptance criteria, rather than left as an unstated gap.Model Used
Claude Opus 5 (claude-opus-5[1m])
Issue Link
Supersedes PR #16145 — a pull request, so no keyword closes it; its content is relocated rather than abandoned, and
mrveiss/mrveiss.github.io#1is where it landed. Closed by hand with that evidence.Closes #16140 — dissolved: with no copy step there are no two sets of bytes to drift apart.
Single-issue rationale
This PR closes one issue, #16140, and cannot ride with another.
It is the second half of a two-repository move, and its safety argument is a dependency on a specific commit having landed elsewhere first —
mrveiss/mrveiss.github.io@34c0d81. Batching it with unrelated work would put that unrelated change behind this dependency, so a problem with the move would block a change that has nothing to do with it.It is also a deletion, and a deletion is reviewed by a different question than a normal change: not is the diff correct — trivially yes, it removes two files — but did the work demonstrably land elsewhere first. Mixing 299 deletions into a batch is how that question stops being asked. Two readers have already read this diff as removing the live site; adding unrelated commits to it would make that misreading more likely, not less.
The only other issue in this scope, #16145, is a pull request rather than an issue, so there is no second issue available to batch with. That is also why this PR says Supersedes rather than Closes for it — and correcting that wording is what dropped the reference count to one and surfaced this gate.
Changelog fragment
Checklist
CLAUDE.mdmrveiss/mrveiss.github.io#2pre-pushran and passedDev_new_gui(notmain)