Repository navigation
Re-verify the thin_mcp_server SPEC page against the merged code - #90
Merged
Merged
Conversation
main is red on check_spec_freshness --strict: thin_mcp_server verified 2026-08-18, code 2026-08-19. The file was edited on both sides of the #71 merge -- f203f0d added the mandatory review guides, 82d682f changed how update_knowledge resolves its entry -- so the merged content differs from both parents and dates to the merge. The check is correct; the page really had not been read against the combination. Three things were actually behind, not just the marker: - mandatory_review_guides was undocumented. It is a governance field, so it belongs in the governance-by-data invariant: cross-owner review procedures from _DIRECT_MANDATORY_REVIEW_GUIDES, failing closed if a path does not resolve, and counted into execution_budget.knowledge_file_reads so an unreadable budget cannot be issued. - The page states that _knowledge_path prevents escaping the knowledge root, which is now not the whole truth: _contributing_entry deliberately resolves outside it, because the contribution entry moved to doc/knowledge/ with the docs. Recorded as the single explicit exception, with why it is safe -- a hardcoded constant path, not caller input, and escape protection is about caller input. - LOC ~806 was stale by about 480 lines; the file is 1286. The refactor note is updated too, since 'about 350 lines of _direct_* helpers' no longer describes it. I am NOT carrying f2e7c42 from the merged branch, which skipped the synthetic PR merge when dating files. It would not have fixed this -- main fails on a push event, where the merge commit is real history -- and it was the wrong idea anyway: on a pull_request run the synthetic merge is exactly what main is about to become, so a file going stale there is a true warning that main will go red after merge. Suppressing it would have turned a correct early failure into a green PR and a red main, which is what just happened. The failing PR run was right. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.
mainis red oncheck_spec_freshness --strict: thin_mcp_server verified 2026-08-18, code 2026-08-19.thin_mcp_server.pywas edited on both sides of the #71 merge —f203f0dadded the mandatory review guides,82d682fchanged howupdate_knowledgeresolves its entry — so the merged content differs from both parents and dates to the merge commit. The check is correct: the page genuinely had not been read against the combination.What was actually behind
Not just the marker — three real gaps:
mandatory_review_guideswas undocumented. It is a governance field, so it belongs in the governance-by-data invariant: cross-owner review procedures from_DIRECT_MANDATORY_REVIEW_GUIDES, failing closed when a path does not resolve, and counted intoexecution_budget.knowledge_file_readsso an unreadable budget cannot be issued._knowledge_pathinvariant was no longer the whole truth. The page says nothing escapes the knowledge root;_contributing_entrydeliberately resolves outside it, because the contribution entry moved todoc/knowledge/with the docs. Now recorded as the single explicit exception, with why it is safe — a hardcoded constant path, not caller input, and escape protection is about caller input.LOC ~806was stale by ~480 lines. The file is 1286. The refactor note is updated too, since "about 350 lines of_direct_*helpers" no longer describes it.What this deliberately does not do
It does not carry
f2e7c42from the #71 branch, which skipped the synthetic PR merge when dating files. That commit would not have fixed this — main fails on a push event, where the merge commit is real history — and it was the wrong idea regardless: on apull_requestrun the synthetic merge is exactly what main is about to become, so a file going stale there is a true warning that main will go red after merge. Suppressing it converts a correct early failure into a green PR and a red main, which is what happened here.Verified locally:
check_spec_freshness --strict0 stale,check_doc_linksOK (290 files), full offline suite green.🤖 Generated with Claude Code