docs: CLAUDE.md — correct the workspace test invocations

[rubenhensen]

Follow-up to the review on #313, which flagged in passing that cargo test --workspace --all-features cannot compile. Checking it turned up a contradiction: that review also said plain cargo test --workspace "passes clean", while CLAUDE.md says it "FAILS to compile". Both halves measured on main (c1682ba) today.

invocation	measured	CLAUDE.md before this PR
cargo test --workspace	passes — 296 tests over 9 binaries + doc-tests	"FAILS to compile"
cargo test -p pg-core	fails, unresolved import crate::test	not mentioned
cargo test --workspace --all-features	fails, web is wasm32-only	not mentioned
cargo test -p pg-core --all-features	fails identically	not mentioned

The documented failure did not disappear, it moved. pg-core's tests are still gated behind its test feature, and cargo test -p pg-core still fails on crate::test::TestSetup exactly as described. What rescues the workspace build is feature unification: cryptify/Cargo.toml dev-depends on pg-core with features = ["rust", "stream", "test"], so the feature is on for every member — cargo tree -e features -p pg-core --workspace shows pg-core feature "test". That has only been true since cryptify joined the workspace on 2026-07-31, which is why the old note was accurate when written. It is one member's dev-dep, not a workspace property, so it reverts if that line changes — worth saying rather than just flipping "fails" to "passes".

The --all-features half is new information and the sharper trap, since CLAUDE.md already recommends --all-features in two places (the CI matrices for pkg/cli/ffi, and the api_gate suite). The distinguishing axis is not per-crate versus workspace-wide, as an earlier draft of this PR claimed: cargo test -p pg-core --all-features fails the same way, so scoping does not make it safe. What makes those two recommendations safe is that pkg, cli and ffi declare no [features] section at all, so --all-features is a no-op for them, and the api_gate suite lives in pg-pkg. pg-core is the only workspace member with a [features] section, so it is the only one --all-features can break — via its compile_error! at pg-core/src/client/web/mod.rs:19.

Reproduce:

cargo test --workspace --no-run                  # ok — 9 executables, plus doc-tests when run
cargo test -p pg-core --no-run                   # error[E0432]: unresolved import `crate::test`
cargo test --workspace --all-features --no-run   # error: "web" feature should only be enabled on wasm32 targets
cargo test -p pg-core --all-features --no-run    # same error — scoping does not help

[dobby-coder]

Thanks for the detailed follow-up on the cargo test discrepancy — I'm on it. Taking a look at PR #314 now and will factor this feature-unification/--all-features context into the review.

[dobby-coder]

The correction is right and the reasoning behind it holds up. I re-measured every claim on this branch (5a7c4dc) rather than reading the prose: cargo test --workspace passes with 296 tests and exit 0; cargo test -p pg-core fails on unresolved import crate::test; the compile_error! sits at pg-core/src/client/web/mod.rs:19; and it really is cryptify's dev-dependency that carries the test feature, not its regular dependency. I also tested the load-bearing causal claim by temporarily dropping test from that dev-dep, and the workspace reverted to E0432 unresolved import crate::test, so feature unification is doing exactly the work the text says it does. Restored afterwards, clean tree.

One sentence in the new text is wrong, and it happens to reintroduce the trap the surrounding paragraph exists to close, so it is worth one more push. Details inline, with the suggested replacement wording.

Rule check: I ran the docs-relevant rules from the memory repo (writing-rules, no-runlog-in-process-rules, no-justification-paragraphs-for-simple-changes, claim-narrowed-in-code-survives-in-the-pr-body, removing-a-mechanism-leaves-docs-outside-the-diff, single-repo-lessons-belong-in-that-repos-claude-md, conventional-commit-pr-titles) and none of them added a finding beyond the one below. Worth recording what they cleared rather than leaving it implicit: the lesson is postguard-specific and lands in postguard's own CLAUDE.md, which is where single-repo lessons belong; cargo test --workspace appears in no other file in the repo, so the corrected claim leaves no stale second copy behind; the verified 2026-08-09 stamp is not run-log bloat here, because the text itself says the passing state can revert, which makes the date load-bearing; and the title passes the Conventional Commit check. All checks are green.

The one prose rule that did fire, em-dash density, I am dropping deliberately: the added text runs 6 em dashes across the bullet where CLAUDE.md already averages about 7 per 1000 words across all 4953 of them. That is this file's established register, not a regression introduced here.

[dobby-coder]

Two notes on this line, one substantive.

The --all-features framing is wrong, and it reopens the trap. The text says:

--all-features is correct per crate (it is what the CI matrices use for pkg/cli/ffi, and what the api_gate suite further down is run with) and wrong workspace-wide.

Per-crate is not the distinguishing axis. I ran it:

cargo test -p pg-core --all-features --no-run
# error: "web" feature should only be enabled on wasm32 targets
#   --> pg-core/src/client/web/mod.rs:19
# error: could not compile `pg-core` (lib) due to 1 previous error

--manifest-path pg-core/Cargo.toml --all-features fails the same way. The axis is whether pg-core is in the selected set, not whether the invocation is scoped to one crate. The three named exceptions are safe only incidentally: pkg, cli and ffi declare no [features] section at all, so --all-features is a no-op for them, and the api_gate suite lives in pg-pkg/tests/api_gate.rs, which is one of those three. As written, an agent trusting this sentence will reach for cargo test -p pg-core --all-features and hit the exact compile_error! the previous sentence just warned about.

Suggested replacement for that clause:

--all-features is correct for the crates that declare no features of their own (pkg/cli/ffi in the CI matrices, and the api_gate suite further down, which lives in pg-pkg) and wrong anywhere pg-core is in the selected set — cargo test -p pg-core --all-features fails identically, so this is not merely a workspace-wide problem.

The same claim is in the PR description ("Both are per-crate and remain correct; only workspace-wide is broken"), so that paragraph needs the same narrowing. A body edit is a PATCH on the PR, no branch push and no CI rerun.

Nit: 296 tests over 10 binaries. The 296 is exact, I summed the test result: lines and got 296 passed, 0 ignored. The count is 9 test binaries plus one doc-test target, though: cargo test --workspace --no-run prints exactly 9 Executable lines. A reader following that repro counts 9 and wonders what they missed. 296 tests over 10 targets (9 binaries + doc-tests) matches what the output actually shows.

I have deliberately not attached suggestion blocks. This bullet is one 493-word line, so a one-click suggestion would have to restate the whole paragraph, and a silent transcription slip in 493 words of backticks and quotes is a worse outcome than two find-and-replace edits.

[dobby-coder]

Thanks for the deep dive — really appreciated the receipts. I reviewed #314 and requested changes: the fix itself is solid (re-verified cargo test --workspace passing, -p pg-core failing, and traced the feature-unification story back to cryptify's dev-dep, so that explanation earns its keep). But the new "correct per crate, wrong workspace-wide" framing isn't quite right — cargo test -p pg-core --all-features fails the same wasm32 compile_error!, since pkg/cli/ffi are only safe because they declare no [features] at all. As written it'd send someone straight into the trap the sentence before it warns about, and the same phrasing is in the PR description too, so both need narrowing. Small nit alongside it: "296 tests over 10 binaries" is 9 binaries plus doc-tests. Left one inline comment on that: #314 (review)

PR: #314

[rubenhensen]

Both fixed in 950f9c4, and the PR description carried the same wrong claim so it is narrowed too.

The --all-features axis. You are right that per-crate was never the distinguishing property, and I confirmed cargo test -p pg-core --all-features --no-run fails on the same compile_error!. Went one step past the suggested wording to name why the three exceptions are exceptions, since "declares no features" is checkable and "is one of pkg/cli/ffi" is a list that rots:

-- pg-core: default rust web stream test
-- pg-pkg:
-- pg-cli:
-- pg-ffi:
-- cryptify:

pg-core is the only member with a [features] section at all, so it is the only member --all-features can break, and the text now says that rather than enumerating safe crates.

The count. 9 Running lines plus Doc-tests pg_core, so 10 test result: lines but 9 binaries — reworded to "296 tests over 10 targets (9 binaries plus pg-core's doc-tests)".

Noting your dropped em-dash finding as correctly dropped: the file's register is what it is, and this bullet should not be the one place that deviates. Also worth recording that you re-derived the causal claim by pulling test out of cryptify's dev-dep and watching the workspace revert to E0432 — that is the check that turns the explanation from plausible into load-bearing, and it is the reason the sentence about it reverting is in the text at all.