Skip to content

verify-stage: add /pharn-verify product command and two-layer verify gate#27

Merged
PrzemekGalarowicz merged 2 commits into
mainfrom
verify-stage
Jul 1, 2026
Merged

verify-stage: add /pharn-verify product command and two-layer verify gate#27
PrzemekGalarowicz merged 2 commits into
mainfrom
verify-stage

Conversation

@PrzemekGalarowicz

@PrzemekGalarowicz PrzemekGalarowicz commented Jul 1, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Adds /pharn-verify, the sixth product-pipeline stage (spec → plan → grill → build → regress → verify → ship), as a command-only increment with no new floor primitive.
  • Adapts /pharn-dev-verify's two-layer pattern to the product side: the floor layer owns the verdict via check-verify.mjs (absolute exit-code threshold over project gates + structural eval pairs); the advisory layer (role: verifier capabilities) annotates only and never flips the verdict (fix Add eval-format contract (structural vs semantic assertion split) #3). Zero verifiers exist today (P7) → floor gates only.
  • Reuses existing floor helpers (check-verify.mjs, count-verifiers.mjs, check-plan-spec-agree.mjs as the fourth spec→plan hash-chain consumer, check-structural.mjs) and emits features/<name>/verify-report.json + features/<name>/VERIFY.md.
  • Includes the build-loop audit trail under .dev/features/verify-stage/ (plan, grill, review, ship, regression/verify reports).

Test plan

  • npm test — floor and hook suites stay green
  • node .dev/floor/validate.mjs . — capability count remains 1 (command is floor-ignored)
  • Run /pharn-verify against a feature with features/<name>/PLAN.md + SPEC.md and confirm verify-report.json + VERIFY.md emit with a deterministic PASS/FAIL verdict
  • Confirm spec→plan hash drift halts before verify runs (chain gate via check-plan-spec-agree.mjs)
  • Confirm a gate exit non-zero at HEAD yields FAIL from check-verify.mjs verdict (verifier findings do not override)
  • Confirm count-verifiers.mjs reports zero registered verifiers (floor-only path exercised)

Made with Cursor

Summary by CodeRabbit

  • New Features

    • Added a new verification stage for the product pipeline, with deterministic pass/fail results and a separate advisory review layer.
    • Added supporting verification and regression reports for the new stage.
  • Documentation

    • Added detailed guidance for the new stage, including execution flow, report outputs, and verification boundaries.
    • Clarified how the stage should behave when checks fail or results are inconclusive.
  • Bug Fixes

    • Improved wording and scope details in the stage guidance to better reflect expected behavior and reporting.

…gate

Introduce the sixth product-pipeline stage with floor-owned verdict (check-verify.mjs) and advisory verifier annotations only.

Co-authored-by: Cursor <cursoragent@cursor.com>
@coderabbitai

coderabbitai Bot commented Jul 1, 2026

Copy link
Copy Markdown

Review Change Stack

📝 Walkthrough

Walkthrough

This PR adds documentation-only artifacts: a new /pharn-verify product command specification defining a two-layer FLOOR/ADVISORY verification pipeline, plus supporting verify-stage dev-loop documents (PLAN, GRILL, REVIEW, REGRESSION, SHIP, VERIFY) and generated JSON verification/regression reports. No exported or public code entities are changed.

Changes

Verify stage command and documentation

Layer / File(s) Summary
/pharn-verify command specification
.claude/commands/pharn-verify.md
Defines the FLOOR (deterministic gate verdict) and ADVISORY (verifier findings) layers, the full step-by-step flow (writes-scope, PLAN/SPEC discovery, hash-chain gate, gate execution, verifier discovery, verdict computation, report emission), the verifier plug-in slot contract, and trust/determinism/cost audits.
Verify-stage plan and grill review
.dev/features/verify-stage/PLAN.md, .dev/features/verify-stage/GRILL.md
Documents the command design rationale, reused floor helpers, contracts satisfied, guarantee/trust/determinism audits, and an advisory GRILL review with four structured findings and verdict.
Verify-stage code review
.dev/features/verify-stage/REVIEW.md
Records a GREEN floor verdict, four evaluation lenses, two advisory findings, and no proposed canon lessons.
Regression verification
.dev/features/verify-stage/REGRESSION.md, .dev/features/verify-stage/regression-report.json
Documents base→head gate comparisons with a no-regressions verdict and the matching JSON artifact.
Ship roll-up and verify artifacts
.dev/features/verify-stage/SHIP.md, .dev/features/verify-stage/VERIFY.md, .dev/features/verify-stage/verify-report.json
Records the gated ship chain outcome, verify certification semantics, and a PASS verify-report JSON with zero registered verifiers.

Estimated code review effort: 2 (Simple) | ~12 minutes

Sequence Diagram(s)

sequenceDiagram
  participant Command as "/pharn-verify"
  participant HashChain as "check-plan-spec-agree.mjs"
  participant Gates as "Deterministic Gate Suite"
  participant Verdict as "check-verify.mjs"
  participant Reports as "verify-report.json / VERIFY.md"

  Command->>HashChain: run spec-plan hash-chain check
  HashChain-->>Command: exit code (GREEN/RED)
  Command->>Gates: run deterministic gates at HEAD
  Gates-->>Command: {gate-id: exit-int} map
  Command->>Verdict: compute verdict from gate results
  Verdict-->>Command: PASS/FAIL/INCONCLUSIVE
  Command->>Reports: emit machine + human artifacts
Loading

Possibly related PRs

  • pharn-dev/pharn-oss#16: Shares the frontmatter-based verifier membership counter (.dev/floor/count-verifiers.mjs) used in this PR's verifier-discovery flow.
  • pharn-dev/pharn-oss#18: Consumes the same verify-report.json deterministic verdict contract this PR defines for gated ship orchestration.
  • pharn-dev/pharn-oss#21: Shares the same .dev/floor/check-plan-spec-agree.mjs hash-chain gate and FLOOR/ADVISORY structure re-checked by this PR.
🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (2 warnings)

Check name Status Explanation Resolution
Linked Issues check ⚠️ Warning The PR adds verify-stage docs and reports, but issue #3 requires pharn-contracts/eval-format.md with structural/semantic contract changes. Add the eval-format contract, structural/semantic split, and skill_kind enum in pharn-contracts/eval-format.md, or link the PR to the correct issue.
Out of Scope Changes check ⚠️ Warning Most changes implement /pharn-verify docs and artifacts, which are unrelated to issue #3's eval-format contract scope. Remove the verify-stage additions from this PR or retarget the PR to the /pharn-verify work and link the eval-format contract separately.
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly names the new /pharn-verify command and its two-layer gate, matching the main change.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch verify-stage

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

…ust audit

Clarify that gate commands come from the user's suite while §3b eval-pair paths are PLAN-derived but bounded to file operands only; record the GATE 2 fix in SHIP.md.

Co-authored-by: Cursor <cursoragent@cursor.com>
@PrzemekGalarowicz PrzemekGalarowicz merged commit 3dc7849 into main Jul 1, 2026
5 of 6 checks passed
@PrzemekGalarowicz PrzemekGalarowicz deleted the verify-stage branch July 1, 2026 11:11

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.dev/features/verify-stage/REVIEW.md:
- Around line 24-25: The `check-verify.mjs` input description is too narrow
because it implies the helper only receives the gate→exit-code map; update the
wording in `REVIEW.md` to reflect that `check-verify.mjs` is invoked with
`results.json` and `--feature <name>`, and rephrase the claim around
`verdict-ownership` to say findings do not affect the verdict rather than saying
it has a sole input.

In @.dev/features/verify-stage/VERIFY.md:
- Around line 18-23: Clarify the VERIFY.md pass criteria so PASS is not
described as being covered by npm run check alone. Update the explanation around
the check flow and the gating logic to explicitly state that the full PASS
outcome also depends on the additional validate and structural:* gates, using
the nearby wording around npm run check, validate, and structural:* to keep the
relationship unambiguous.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 77921223-b2b8-4a42-964a-a42a7675e00e

📥 Commits

Reviewing files that changed from the base of the PR and between 4e508ab and 9f64664.

📒 Files selected for processing (9)
  • .claude/commands/pharn-verify.md
  • .dev/features/verify-stage/GRILL.md
  • .dev/features/verify-stage/PLAN.md
  • .dev/features/verify-stage/REGRESSION.md
  • .dev/features/verify-stage/REVIEW.md
  • .dev/features/verify-stage/SHIP.md
  • .dev/features/verify-stage/VERIFY.md
  • .dev/features/verify-stage/regression-report.json
  • .dev/features/verify-stage/verify-report.json

Comment on lines +24 to +25
and verdict-ownership is shown **structural** (the helper's sole input is the gate→exit-code map — it
cannot receive a finding). "ensures the feature is correct" is explicitly **struck** as the P0 disease.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

Tighten the check-verify.mjs input claim.

check-verify.mjs is invoked with results.json plus --feature <name>, so it does not take only the gate→exit map. Rephrase this as “findings do not affect the verdict” instead of “sole input.”

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.dev/features/verify-stage/REVIEW.md around lines 24 - 25, The
`check-verify.mjs` input description is too narrow because it implies the helper
only receives the gate→exit-code map; update the wording in `REVIEW.md` to
reflect that `check-verify.mjs` is invoked with `results.json` and `--feature
<name>`, and rephrase the claim around `verdict-ownership` to say findings do
not affect the verdict rather than saying it has a sole input.

Comment on lines +18 to +23
- The `format:check` + `lint:md` + `lint` + `test` set is exactly the repo's `npm run check` aggregate, so
the verdict tracks the full `npm run check` (L9 — cited, not restated, P4).
- The `structural:*` gate is the one committed eval pair the feature surface ships
(`pharn-review/trust-fence/evals/expected/expected-injection-comment.json` ↔
`.dev/features/trust-fence/findings.json`). This increment added **no** new eval pair (it ships a
floor-ignored command + audit scaffolding), so this pre-existing pair is the only `structural:*` gate.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Clarify that PASS is broader than npm run check.

Lines 18-19 say this set is “exactly” the repo’s npm run check aggregate, but lines 12 and 16 add validate and structural:* gates on top. As written, a clean npm run check still wouldn’t guarantee PASS.

♻️ Proposed wording fix
- The `format:check` + `lint:md` + `lint` + `test` set is exactly the repo's `npm run check` aggregate, so
-  the verdict tracks the full `npm run check` (L9 — cited, not restated, P4).
+ The `format:check` + `lint:md` + `lint` + `test` set matches the repo's `npm run check` aggregate.
+ The verify verdict also depends on the `validate` and `structural:*` gates above.
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
- The `format:check` + `lint:md` + `lint` + `test` set is exactly the repo's `npm run check` aggregate, so
the verdict tracks the full `npm run check` (L9 — cited, not restated, P4).
- The `structural:*` gate is the one committed eval pair the feature surface ships
(`pharn-review/trust-fence/evals/expected/expected-injection-comment.json`
`.dev/features/trust-fence/findings.json`). This increment added **no** new eval pair (it ships a
floor-ignored command + audit scaffolding), so this pre-existing pair is the only `structural:*` gate.
The `format:check` + `lint:md` + `lint` + `test` set matches the repo's `npm run check` aggregate.
The verify verdict also depends on the `validate` and `structural:*` gates above.
- The `structural:*` gate is the one committed eval pair the feature surface ships
(`pharn-review/trust-fence/evals/expected/expected-injection-comment.json`
`.dev/features/trust-fence/findings.json`). This increment added **no** new eval pair (it ships a
floor-ignored command + audit scaffolding), so this pre-existing pair is the only `structural:*` gate.
🧰 Tools
🪛 LanguageTool

[style] ~18-~18: Consider an alternative for the overused word “exactly”.
Context: ...k+lint:md+lint+testset is exactly the repo'snpm run check` aggregate, s...

(EXACTLY_PRECISELY)

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.dev/features/verify-stage/VERIFY.md around lines 18 - 23, Clarify the
VERIFY.md pass criteria so PASS is not described as being covered by npm run
check alone. Update the explanation around the check flow and the gating logic
to explicitly state that the full PASS outcome also depends on the additional
validate and structural:* gates, using the nearby wording around npm run check,
validate, and structural:* to keep the relationship unambiguous.

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.

1 participant