Repository navigation
release: 0.7.0 — the diagnostics get a home and the changelog catches up - #16
Merged
Merged
Conversation
Problem Orrery gained three read-only diagnostics in three separate pull requests — the capability planner (#7), the tool-surface review (#8), and the semantic compatibility doctor (#9). Each arrived with a sentence appended wherever its own change happened to touch the README, so two of them ended up as orphan paragraphs below the development gate and the third existed only as a comment inside a code block. Read individually they look like three unrelated utilities. They are not: they are the same capability at three different moments — before you choose a client, after you install, and whenever the tool surface moves. That framing was nowhere on the page, so the most checkable thing about this project was also the least visible. Approach Add "Interrogate it yourself" between "What it will not do" and "When not to use this", so the honesty block reads in one run: what it refuses to do, how you can check that for yourself, and when you should not use it at all. The section is organised by moment rather than by tool, and each entry leads with what the command *refuses* to do, because that is the part with value. A path-only portability matrix would report six clients as working; the planner names the ones that would quietly downgrade advisor isolation and refuses them. The doctor separates what it observed on disk from what it cannot know about runtime behaviour. The review turns "the digest moved" into whether the thing that moved can take a new argument, hold state, or has dropped a `readOnlyHint`. It closes by inverting the usual precedence: if a diagnostic disagrees with the README, the README is wrong. Verification Every documented invocation was run, not copied from a pull request description. `plan` with the documented flags returns `bestFit: codex` and refuses cursor and the remaining clients. `tools:review` returns `changed: false`, `permissionExpansion: false`. `doctor` reports schema 2 with `readOnlyMechanism` and per-role adapter state. `bun run ci` is green. Impact Documentation only.
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.
The final pull request before tagging v0.7.0. Two commits: a README section, and the release record.
1 · The three diagnostics get a home
#7, #8 and #9 each added a read-only diagnostic, and each appended a sentence wherever its own change happened to touch the README. Two ended up as orphan paragraphs below the development gate; the third existed only as a comment inside a code block.
Read separately they look like three unrelated utilities. They aren't — they're the same capability at three moments:
bun run planbun run doctorbun run tools:reviewNew "Interrogate it yourself" section, placed between What it will not do and When not to use this, so the honesty block reads in one run: what it refuses to do → how you check that yourself → when you shouldn't use it at all. Organised by moment rather than by tool, each entry leading with what the command refuses to do. It closes by inverting the usual precedence: if a diagnostic disagrees with the README, the README is wrong.
Every documented invocation was run, not copied from a PR description:
2 · The changelog catches up, and 0.7.0 is cut
Four pull requests merged into
mainwithout a changelog entry between them — #9, #8, #7 and #15. The Unreleased section described only the Astra lane, so the three most user-visible additions since 0.6.0 existed in the code and in the README but nowhere in the release record. A changelog that silently omits four merges is worse than none, because it is read as complete.All four are now documented, Unreleased is cut as 0.7.0, and the three declared versions agree.
Minor rather than patch: this release adds a second native implementation lane and three read-only diagnostics. Nothing is removed and no interface breaks, so it is not a major — though 1.0.0 is a maintainer's call rather than a semver one, and this is arguably the release that earns it.
Verification
VERIFY PASSEDthree-role · 82 tests across 6 files, 0 fail · validate · sbom now emittingorrery-0.7.0.cdx.json(18 packaged files, 0 runtime dependencies) · release-check · tag-check passes for v0.7.0, so the tag and all three manifests agree.Not in this PR
The three README images. They were generated, but they are branded FABLEWRIGHT rather than ORRERY, and the refusal image shows two role filenames and an install command that do not exist in this repository. Embedding them would put a claim on the front page that the shipped files contradict — the exact failure
verify.shguards against. They land in a follow-up once corrected.Risk
Documentation and version metadata only. No code, no behaviour change.