Skip to content

Claude/init 1wgqn0 - #14

Merged
SuperInstance merged 2 commits into
masterfrom
claude/init-1wgqn0
Aug 18, 2026
Merged

Claude/init 1wgqn0#14
SuperInstance merged 2 commits into
masterfrom
claude/init-1wgqn0

Conversation

@SuperInstance

Copy link
Copy Markdown
Owner

Description

[What changed and why. Link to the issue if one exists.]

Testing Done

[How you verified the change works — test output, manual steps, screenshots]


  • Tests added/updated
  • Docs updated (if behavior changed)
  • No breaking changes (or changelog entry added)
  • CI/CD passes

Reviewer notes: [Optional — anything you want the reviewer to know upfront]

claude added 2 commits August 18, 2026 20:45
Everything in tests/ runs with the repository on sys.path and every data file
sitting where the source says it is. That is the wrong shape for the failures
releases have. The specs once lived in a top-level specs/ directory and
`plainsong spec` reported "no specs found" to everybody who installed rather
than cloned -- the self-verification the whole design leans on, quietly doing
nothing, with a green suite. The songbook had the same fault. Neither test
could have caught either.

So this script never imports plainsong. It builds a wheel, installs it into a
throwaway venv outside the source tree, and drives the console script from
/tmp with PYTHONPATH stripped, because leaving it set is exactly how a
packaging bug hides: the installed package imports and the module that answers
is the one in the checkout. Then it repeats the drill against what is actually
on PyPI, which is a separate question -- the tree can be right and the upload
a version behind, and PyPI's JSON API twice reported an older version than pip
then resolved.

It checks the things that are only true from outside: that spec reads its
TOMLs out of the install, that the songbook is really packaged, that a compile
produces notes rather than just a file, that the rebinding guard is correct in
the shipped artifact, that the MCP server answers real JSON-RPC over stdio,
and that the sibling's loopback check agrees with the compiler's case by case.

A check that cannot run counts as a failure rather than a skip. "We did not
look" and "we looked and it was fine" are the two things this exists to keep
apart.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PBAjxy7cD6DzJ72NX8TJEc
Its first run reported two failures, both its own. `--json` is a global flag
and has to precede the subcommand -- `plainsong --json info x`, not
`plainsong info x --json`, which argparse rejects outright -- and the note
total is `arrangement.notes` rather than a top-level key, the per-track counts
living under `arrangement.tracks[].notes`.

Nothing about the product was wrong. Every check that tests plainsong itself
passed against both the built wheel and the published package, including the
packaging canary, the bundled songbook, the rebinding guard in the shipped
artifact, and the MCP server answering real JSON-RPC over stdio.

Worth recording separately: CLAUDE.md says "Every command takes --json", which
is true only of the global position. Following it literally is what produced
this bug.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PBAjxy7cD6DzJ72NX8TJEc
@SuperInstance
SuperInstance merged commit c628833 into master Aug 18, 2026
16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants