rickub
rickub/clipublic Fork
⑂ main
Branches
feat/10-repo-rename-transfer feat/7-edit-title-and-body feat/8-run-logs-job-filter feat/staleness-notice main test/create-body-dash-stdin
Tags
v0.1.0 v0.1.0-rc.11 v0.1.0-rc.14 v0.1.0-rc.16 v0.1.0-rc.20 v0.1.0-rc.26 v0.1.0-rc.36 v0.1.0-rc.43 v0.1.0-rc.50 v0.1.0-rc.64 v0.2.0 View all branches → View all tags →
Commits
⬇ Clone ▾
git clone https://git.rickub.com/rickub/cli.git
git clone ssh://git@rickub.com/rickub/cli.git

Host key fingerprint (ed25519): SHA256:iycHnxEyq0Q7uyVpB7JlznP0G7JrTPXLYRcAU5CSLhc — verify it before your first connect.

Download ZIP

inline.go claims conformance tests that were deleted with the monorepo; pin InlineIntents/InlineSides to a published vocabulary #14

Open@ogirardot opened this issue 5d ago
  • @ogirardot opened this issue · 5d ago

    What broke

    internal/api/inline.go still opens with (verified on main @ 37ea74d):

    TestCLIInlineIntentsMatchStore and TestCLIInlineSidesMatchStore in web/cli_intent_conformance_test.go parse THIS file and the store constants and fail (in the web CI job, which is the one that runs) naming the file to edit if the two ever disagree.

    Those tests no longer exist. They were deleted when cli/ left the rickub monorepo (2026-09-06): web/cli_intent_conformance_test.go in rickub/rickub now carries only the in-repo pins, and no CI job in either repository diffs this file against anything. The header claims a conformance test that would catch drift; there is none. The copy is rung 0 wearing a rung-3 comment — the exact arrangement CLAUDE.md forbids.

    Evidence

    • rickub/rickub issue #338 (2026-09-06) tracks the enforcement gap end to end; its in-repo half landed 2026-10-10 (every layer inside rickub/rickub — write-path 400s, store round-trip vs the CHECK constraints, view literals, render cases, and the published docs enumeration — is now conformance-pinned there).
    • What remains is THIS file: var InlineIntents = []string{"info", "request_change", "kudos"} and var InlineSides = []string{"old", "new"} are hand-maintained against web/store/pr_inline_comments.go (migration 0045's CHECK constraints) with nothing holding them together but the stale comment above.

    Impact

    Low frequency, high blast radius, silent in both directions:

    • rickub/rickub adds an intent → the CLI rejects it client-side ("unknown --intent") while the web UI, JSON API and MCP all accept it — rickub pr comment --intent <new> is impossible.
    • this repo adds one without the store following → rickub pr comment posts a request the API 400s, with no test here failing first.

    Acceptance criterion

    The stale header claim is replaced by a real mechanism. Either rung from #338:

    • Rung 2 (generated): rickub/rickub publishes the vocabulary as a small artifact (a JSON file on a release, or a generated .go in a tiny shared module this repo can require), and InlineIntents/InlineSides here are generated from it and marked generated.
    • Rung 3 (conformance-tested): this repo's CI fetches the canonical list from a stable URL (e.g. an endpoint on rickub.com serving store.InlineIntents() / the sides) and fails naming internal/api/inline.go on any mismatch — set or canonical order (the deleted tests asserted ORDER, not just membership).

    Closing requires the mechanism proven to bite: change one constant on a scratch branch and watch the check fail naming internal/api/inline.go.

    Until then, fix the header comment to stop claiming the deleted tests exist — a false "kept honest by tests" is worse than none, because it tells the next reader the safety net is already up.

Sign in to comment.