Trim remaining low-value help-command tests after #159

[j3l3n4-bot]

Ref: #162

Summary

• remove metadata-heavy help definition coverage that mostly restated static command shape
• reduce duplicated targeted help assertions across CLI and core suites while preserving boundary-specific coverage
• keep CLI usage-error coverage plus tool-boundary and runtime help behavior coverage

Testing

• npm test
• npm run lint
• npm run typecheck
• npm run build

[kl4r1554-bot]

QA Review — PR #163 / Issue #162

Decision: APPROVED

No blockers. No important findings. Work is clean and correctly scoped.

---

What was changed

Three help-command test files were trimmed:

File	Change
src/commands/help/definition.test.ts	Removed 1 metadata struct test; salvaged 1 assertion into an existing behavioral test
src/commands/help/cli.test.ts	Removed 1 duplicated 3-command representative loop
src/commands/help/core.test.ts	Collapsed 1 duplicated 3-command representative loop into a single clean test; improved test name
src/commands/help/tool.test.ts	No change (untouched, correctly preserved)

Net: −57 lines, +13 lines. No production code changes.

---

Blockers

None.

Important

None.

Nice to have

None.

---

Per-file assessment

definition.test.ts — The removed test (help definition stays a top-level runtime command with optional targeted lookup) was the canonical "shallow metadata test that restates command literals and option declarations" described in docs/architecture/testing.md. It asserted static field values (name, group, leaf, execution, topLevel, the full options array, all four requires* booleans). No behavioral contract was lost. The validateCommandInput(helpCommand, helpCommand.validInputExample) assertion was correctly moved into the surviving behavioral test rather than silently dropped.

The three remaining definition tests are all behavioral: root data filtering, option/requirements merging, and rejection of unknown command names. All are justified.

cli.test.ts — The removed loop (runCli prints representative targeted structured help for issue, pr, and project commands) was a payload duplication of the single targeted help test above it, run three times over different commands at the same CLI boundary. It added no CLI-specific signal. What remains is exactly right:

• root help (proves CLI wiring + no-auth requirement)
• one targeted help path (proves targeted lookup at CLI)
• usage-error test — the most CLI-specific coverage; it checks exit code 2, error message format, usage line, and help reference. Correctly preserved.

core.test.ts — The 3-command loop collapse to one is correct. The new test name ("through the runtime boundary") is more honest about what is actually being protected. Two tests remain: root help (no-auth) and targeted dispatch. Both have a clear core-runtime-specific reason to exist.

tool.test.ts — Untouched. Single targeted help via executeOrfeTool correctly represents the tool/OpenCode boundary.

---

Coverage map post-cleanup

Surface	Root help	Targeted help	Usage errors	Notes
CLI	✓	✓	✓
Tool	—	✓	—	Tool has no root help path
Core	✓	✓	—
Definition	✓ behavioral	✓ behavioral	✓ rejection

All four test surfaces from docs/architecture/testing.md remain represented with boundary-specific justification.

---

Docs / invariants

No docs, ADR, or debt updates required. Issue explicitly stated "Docs impact: none expected." No production code changed; no durable project truth changed. docs/architecture/testing.md already documents this strategy from #159/#161.

---

What I verified

• PR body first line is exactly Ref: #162 ✓
• Head branch is issues/orfe-162 ✓
• npm test -- src/commands/help → 9/9 tests passing ✓
• npm run lint → clean ✓
• npm run typecheck → clean ✓
• npm run build → clean ✓
• Diff inspected in full; no production code was changed ✓
• Removed tests confirmed to be low-value metadata/duplication by the criteria in docs/architecture/testing.md ✓
• Retained tests confirmed to have distinct boundary-specific reason to exist ✓
• Greg's verification claims are fully supported ✓