docs: remove the empty testing heading from the README #4

jercik · 2026-10-22T17:42:54Z

jercik commented

2026-10-22 17:42:54 +00:00

Removes the empty # Testing hooks heading that review of #3 found at the end of the README.

🤖 Generated with Claude Code

Removes the empty `# Testing hooks` heading that review of https://code.j4k.dev/j4k-oss/perplexity-agent-mcp/pulls/3 found at the end of the README. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

jercik added 1 commit

2026-10-22 17:42:54 +00:00

docs: remove the empty testing heading from the README

Checks / pr-flow-canary (pull_request) Has been skipped

Details

Checks / reuse (pull_request) Successful in 4s

Details

commit-msg / commitlint (pull_request) Successful in 10s

Details

Checks / quality-checks (24.15.0) (pull_request) Successful in 41s

Details

Checks / quality-checks (26.5.0) (pull_request) Successful in 42s

Details

Review / Review (pull_request_target) Successful in 3m6s

Details

f32e196d30

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

jercik referenced this pull request

2026-10-22 17:44:16 +00:00

docs: fix stale README Node version and source pointers #3

forgejo-actions commented

2026-10-22 17:45:58 +00:00

Review 01M5JBAZ7W4NBGQYE07XQT116Y — head f32e196d30e94aeedbebfc7a563fcf09e0ea2d99

Review — j4k-oss/perplexity-agent-mcp @ `86a9a148b5`

Scope: diff against base tree 202843f6ef87
Status: dispatched — coverage complete (3/3 slots terminal)
Facts: current review-wide projection

Computed under:

{
  "abandonment": "abandonment-v1",
  "anchor_recipe": 1,
  "batch_policy": "batch-v1",
  "coverage": "coverage-v3",
  "dispatch_policy": "dispatch-v2",
  "grounder_version": 1,
  "grounding_read_rule": "grounding-read-v1",
  "promotion_policy": "promotion-v1",
  "report": "report-v4",
  "tally": "tally-v1",
  "triage_settle": "triage-settle-v2"
}

Findings (2)

medium — The setup requirements admit unsupported Node.js versions

claim: 01M5JBDCWK57HHES7WBV3S2JHP
anchor: README.md (snippet)

- Node.js v24.0.0 or newer

lens: writing-quality · arm: default
verdicts: 1 valid / 0 invalid / 0 uncertain
- pass 01M5JBEN8AQR0E04HF10MN159X · valid: The exact-grounded README prerequisite admits Node.js 24.0.0 onward, while the reviewer reports the concrete governing declaration package.json engines.node = >=24.15.0. Thus versions below 24.15.0 satisfy the README but fall outside declared support. Conditional engine rejection is plausible without asserting a reproduced runtime failure. The historical claim and rationale describe the same comparison and supply no refutation; there is no owner closure to apply. The installation reader needs the minimum when choosing a runtime, so retaining the precise prerequisite is task-critical rather than an unnecessary inventory. Align it with >=24.15.0 or derive it from package metadata. Medium severity is supported.
disposition: none

A reader using Node.js 24.0.0 through 24.14.x would conclude that they meet the installation prerequisite, even though the package declares those versions unsupported. This can lead to engine warnings or installation rejection when engine checks are enforced.

The Requirements section says ‘Node.js v24.0.0 or newer’, whereas package.json declares engines.node as >=24.15.0. The checks workflow also uses 24.15.0 as its lowest Node.js matrix entry.

Change the requirement to ‘Node.js v24.15.0 or newer’. The README serves the installer’s prerequisite check, so the exact minimum belongs here: a source pointer alone would require the reader to inspect package metadata before choosing a runtime. This preserves the task-critical prerequisite and follows the writing standards’ requirements for precise, verifiable claims and sufficient interface guidance.

I read README.md, package.json, and .forgejo/workflows/checks.yml. This is a documented-support mismatch established by static comparison; I did not test runtime failure on older Node.js versions. Agreement between the README and the governing engines.node value would resolve the claim; successful execution on an older runtime alone would not establish declared support.

medium — The implementation overview independently inventories the model selection

claim: 01M5JBE124AKC1DFK5DWMK1JHT
anchor: README.md (snippet)

Under the hood, both tools are opinionated wrappers that call Perplexity API with coding-specialized system prompts. The lookup tool uses a compact fact‑extraction prompt focused on code/docs facts (see `LOOKUP_SYSTEM_PROMPT` in `src/index.ts`). The answer tool uses a technical decision/analysis prompt tailored for migrations and architecture choices (see `ANSWER_SYSTEM_PROMPT` in `src/index.ts`). The server also selects task‑appropriate Perplexity models—`sonar-pro` for lookups (see `getLookupModel()` in `src/index.ts`) and `sonar-reasoning-pro` for deeper research (see `getAnswerModel()` in `src/index.ts`).

lens: writing-quality · arm: default
verdicts: 1 valid / 0 invalid / 0 uncertain
- pass 01M5JBEN8AQR0E04HF10MN159X · valid: The exact-grounded paragraph manually lists lookup -> sonar-pro and answer -> sonar-reasoning-pro. The reviewer identifies the authorities and their entries: registerLookupTool in src/tools/lookup.ts and registerAnswerTool in src/tools/answer.ts select those same models, with no unmatched member. This is the subject's model selection, not the vendor's externally defined catalog. The implementation overview offers no distinct task requiring those exact identifiers; pointers to the selection definitions remove an independent maintenance copy. Medium severity applies because the copied selection still agrees. Separately, the reviewer concretely reports that the prompt constants live in src/prompts.ts and the named getters have no definitions, supporting the misleading-pointer allegation. The supported defects do not depend on accepting the whole rewrite. Its removal of prompt-role explanations relies on preceding descriptions outside any grounded batch anchor, so that broader cut cannot be fully assessed. A compatible narrower correction keeps the compact-fact-extraction versus decision/analysis explanation, corrects the prompt pointers, and replaces model identifiers and nonexistent getters with the reported registration-function pointers.
disposition: none

Changing a tool’s model requires a separate README edit to keep this implementation overview accurate. The paragraph also sends readers to src/index.ts for prompt definitions and model getters that are absent there, preventing them from following its claimed authorities.

The source-defined selection is lookup → sonar-pro in registerLookupTool in src/tools/lookup.ts, and answer → sonar-reasoning-pro in registerAnswerTool in src/tools/answer.ts. The prose copies lookup → sonar-pro and answer → sonar-reasoning-pro. Neither list has an unmatched member. This is the subject’s selection of vendor models, not an inventory of models the vendor offers. The prompt constants actually live in src/prompts.ts; a tree search finds no getLookupModel or getAnswerModel definition.

Replace the paragraph with: ‘Both tools call the Perplexity API with coding-focused system prompts. For prompt definitions, see LOOKUP_SYSTEM_PROMPT and ANSWER_SYSTEM_PROMPT in src/prompts.ts. Model selection is defined in registerLookupTool in src/tools/lookup.ts and registerAnswerTool in src/tools/answer.ts.’ Format the identifiers and paths as code. This preserves the implementation reader’s explanation and provides working source pointers without copying the selection. The preceding tool descriptions already tell users which tool to choose; exact model identifiers are not needed for that choice or as inputs to either tool. This follows One Idea, One Place’s distinction between task-serving interface details and implementation inventories.

I read README.md, src/index.ts, src/prompts.ts, src/server.ts, both tool registration files, and their calls to performChatCompletion in src/perplexity-client.ts, then searched the tree for the named constants, getters, and model identifiers. This is a static documentation comparison. A data flow that generates this paragraph from the model selections, or a distinct reader action requiring the model names inline, would refute the maintenance-copy concern; neither is evidenced in the examined files.

Other claims

grounding-pending (0)
ungrounded (0)
rejected (0)
duplicate-of (0)
unadjudicated (0)

Coverage

Coverage pass: 01M5JBBCF8BY26BQCNVNFQPJXN
Accounting: complete
Slot health: healthy

lens	part	arm	unit status	runs	loss
restated-sets	whole	default	no-claims	1	no
project-docs	whole	default	no-claims	1	no
writing-quality	whole	default	claims-emitted	1	no

general-bug — skipped-by-dispatch: only a README heading removal; no code changed
test-trimming — skipped-by-dispatch: no tests changed
unix-cli — skipped-by-dispatch: no CLI code or behavior changed
use-effect — skipped-by-dispatch: no React code changed; diff is README only
react — skipped-by-dispatch: no React code changed; diff is README only

**Review** `01M5JBAZ7W4NBGQYE07XQT116Y` — head `f32e196d30e94aeedbebfc7a563fcf09e0ea2d99` # Review — j4k-oss/perplexity-agent-mcp @ 86a9a148b5fb Scope: diff against base tree `202843f6ef87` Status: dispatched — coverage complete (3/3 slots terminal) Facts: current review-wide projection Computed under: ```json { "abandonment": "abandonment-v1", "anchor_recipe": 1, "batch_policy": "batch-v1", "coverage": "coverage-v3", "dispatch_policy": "dispatch-v2", "grounder_version": 1, "grounding_read_rule": "grounding-read-v1", "promotion_policy": "promotion-v1", "report": "report-v4", "tally": "tally-v1", "triage_settle": "triage-settle-v2" } ``` ## Findings (2) ### medium — The setup requirements admit unsupported Node.js versions - claim: `01M5JBDCWK57HHES7WBV3S2JHP` - anchor: `README.md` (snippet) ``` - Node.js v24.0.0 or newer ``` - lens: writing-quality · arm: default - verdicts: 1 valid / 0 invalid / 0 uncertain - pass `01M5JBEN8AQR0E04HF10MN159X` · valid: The exact-grounded README prerequisite admits Node.js 24.0.0 onward, while the reviewer reports the concrete governing declaration package.json engines.node = >=24.15.0. Thus versions below 24.15.0 satisfy the README but fall outside declared support. Conditional engine rejection is plausible without asserting a reproduced runtime failure. The historical claim and rationale describe the same comparison and supply no refutation; there is no owner closure to apply. The installation reader needs the minimum when choosing a runtime, so retaining the precise prerequisite is task-critical rather than an unnecessary inventory. Align it with >=24.15.0 or derive it from package metadata. Medium severity is supported. - disposition: none > A reader using Node.js 24.0.0 through 24.14.x would conclude that they meet the installation prerequisite, even though the package declares those versions unsupported. This can lead to engine warnings or installation rejection when engine checks are enforced. > > The Requirements section says ‘Node.js v24.0.0 or newer’, whereas package.json declares engines.node as >=24.15.0. The checks workflow also uses 24.15.0 as its lowest Node.js matrix entry. > > Change the requirement to ‘Node.js v24.15.0 or newer’. The README serves the installer’s prerequisite check, so the exact minimum belongs here: a source pointer alone would require the reader to inspect package metadata before choosing a runtime. This preserves the task-critical prerequisite and follows the writing standards’ requirements for precise, verifiable claims and sufficient interface guidance. > > I read README.md, package.json, and .forgejo/workflows/checks.yml. This is a documented-support mismatch established by static comparison; I did not test runtime failure on older Node.js versions. Agreement between the README and the governing engines.node value would resolve the claim; successful execution on an older runtime alone would not establish declared support. ### medium — The implementation overview independently inventories the model selection - claim: `01M5JBE124AKC1DFK5DWMK1JHT` - anchor: `README.md` (snippet) ``` Under the hood, both tools are opinionated wrappers that call Perplexity API with coding-specialized system prompts. The lookup tool uses a compact fact‑extraction prompt focused on code/docs facts (see `LOOKUP_SYSTEM_PROMPT` in `src/index.ts`). The answer tool uses a technical decision/analysis prompt tailored for migrations and architecture choices (see `ANSWER_SYSTEM_PROMPT` in `src/index.ts`). The server also selects task‑appropriate Perplexity models—`sonar-pro` for lookups (see `getLookupModel()` in `src/index.ts`) and `sonar-reasoning-pro` for deeper research (see `getAnswerModel()` in `src/index.ts`). ``` - lens: writing-quality · arm: default - verdicts: 1 valid / 0 invalid / 0 uncertain - pass `01M5JBEN8AQR0E04HF10MN159X` · valid: The exact-grounded paragraph manually lists lookup -> sonar-pro and answer -> sonar-reasoning-pro. The reviewer identifies the authorities and their entries: registerLookupTool in src/tools/lookup.ts and registerAnswerTool in src/tools/answer.ts select those same models, with no unmatched member. This is the subject's model selection, not the vendor's externally defined catalog. The implementation overview offers no distinct task requiring those exact identifiers; pointers to the selection definitions remove an independent maintenance copy. Medium severity applies because the copied selection still agrees. Separately, the reviewer concretely reports that the prompt constants live in src/prompts.ts and the named getters have no definitions, supporting the misleading-pointer allegation. The supported defects do not depend on accepting the whole rewrite. Its removal of prompt-role explanations relies on preceding descriptions outside any grounded batch anchor, so that broader cut cannot be fully assessed. A compatible narrower correction keeps the compact-fact-extraction versus decision/analysis explanation, corrects the prompt pointers, and replaces model identifiers and nonexistent getters with the reported registration-function pointers. - disposition: none > Changing a tool’s model requires a separate README edit to keep this implementation overview accurate. The paragraph also sends readers to src/index.ts for prompt definitions and model getters that are absent there, preventing them from following its claimed authorities. > > The source-defined selection is lookup → sonar-pro in registerLookupTool in src/tools/lookup.ts, and answer → sonar-reasoning-pro in registerAnswerTool in src/tools/answer.ts. The prose copies lookup → sonar-pro and answer → sonar-reasoning-pro. Neither list has an unmatched member. This is the subject’s selection of vendor models, not an inventory of models the vendor offers. The prompt constants actually live in src/prompts.ts; a tree search finds no getLookupModel or getAnswerModel definition. > > Replace the paragraph with: ‘Both tools call the Perplexity API with coding-focused system prompts. For prompt definitions, see LOOKUP_SYSTEM_PROMPT and ANSWER_SYSTEM_PROMPT in src/prompts.ts. Model selection is defined in registerLookupTool in src/tools/lookup.ts and registerAnswerTool in src/tools/answer.ts.’ Format the identifiers and paths as code. This preserves the implementation reader’s explanation and provides working source pointers without copying the selection. The preceding tool descriptions already tell users which tool to choose; exact model identifiers are not needed for that choice or as inputs to either tool. This follows One Idea, One Place’s distinction between task-serving interface details and implementation inventories. > > I read README.md, src/index.ts, src/prompts.ts, src/server.ts, both tool registration files, and their calls to performChatCompletion in src/perplexity-client.ts, then searched the tree for the named constants, getters, and model identifiers. This is a static documentation comparison. A data flow that generates this paragraph from the model selections, or a distinct reader action requiring the model names inline, would refute the maintenance-copy concern; neither is evidenced in the examined files. ## Other claims - grounding-pending (0) - ungrounded (0) - rejected (0) - duplicate-of (0) - unadjudicated (0) ## Coverage Coverage pass: 01M5JBBCF8BY26BQCNVNFQPJXN Accounting: complete Slot health: healthy | lens | part | arm | unit status | runs | loss | | --- | --- | --- | --- | --- | --- | | restated-sets | whole | default | no-claims | 1 | no | | project-docs | whole | default | no-claims | 1 | no | | writing-quality | whole | default | claims-emitted | 1 | no | - general-bug — skipped-by-dispatch: only a README heading removal; no code changed - test-trimming — skipped-by-dispatch: no tests changed - unix-cli — skipped-by-dispatch: no CLI code or behavior changed - use-effect — skipped-by-dispatch: no React code changed; diff is README only - react — skipped-by-dispatch: no React code changed; diff is README only

🚀 1

forgejo-actions reviewed

2026-10-22 17:45:58 +00:00

README.md

					
				@ -61,5 +61,3 @@ Please update the "foo" dependency to the latest version. Use Perplexity for the

				- Node.js v24.0.0 or newer

medium — The setup requirements admit unsupported Node.js versions

A reader using Node.js 24.0.0 through 24.14.x would conclude that they meet the installation prerequisite, even though the package declares those versions unsupported. This can lead to engine warnings or installation rejection when engine checks are enforced.

The Requirements section says ‘Node.js v24.0.0 or newer’, whereas package.json declares engines.node as >=24.15.0. The checks workflow also uses 24.15.0 as its lowest Node.js matrix entry.

Change the requirement to ‘Node.js v24.15.0 or newer’. The README serves the installer’s prerequisite check, so the exact minimum belongs here: a source pointer alone would require the reader to inspect package metadata before choosing a runtime. This preserves the task-critical prerequisite and follows the writing standards’ requirements for precise, verifiable claims and sufficient interface guidance.

I read README.md, package.json, and .forgejo/workflows/checks.yml. This is a documented-support mismatch established by static comparison; I did not test runtime failure on older Node.js versions. Agreement between the README and the governing engines.node value would resolve the claim; successful execution on an older runtime alone would not establish declared support.

lens writing-quality · arm default · tally 1 valid / 0 invalid / 0 uncertain
claim 01M5JBDCWK57HHES7WBV3S2JHP of review 01M5JBAZ7W4NBGQYE07XQT116Y

**medium** — The setup requirements admit unsupported Node.js versions > A reader using Node.js 24.0.0 through 24.14.x would conclude that they meet the installation prerequisite, even though the package declares those versions unsupported. This can lead to engine warnings or installation rejection when engine checks are enforced. > > The Requirements section says ‘Node.js v24.0.0 or newer’, whereas package.json declares engines.node as >=24.15.0. The checks workflow also uses 24.15.0 as its lowest Node.js matrix entry. > > Change the requirement to ‘Node.js v24.15.0 or newer’. The README serves the installer’s prerequisite check, so the exact minimum belongs here: a source pointer alone would require the reader to inspect package metadata before choosing a runtime. This preserves the task-critical prerequisite and follows the writing standards’ requirements for precise, verifiable claims and sufficient interface guidance. > > I read README.md, package.json, and .forgejo/workflows/checks.yml. This is a documented-support mismatch established by static comparison; I did not test runtime failure on older Node.js versions. Agreement between the README and the governing engines.node value would resolve the claim; successful execution on an older runtime alone would not establish declared support. lens `writing-quality` · arm `default` · tally 1 valid / 0 invalid / 0 uncertain claim `01M5JBDCWK57HHES7WBV3S2JHP` of review `01M5JBAZ7W4NBGQYE07XQT116Y`

👍 1

Already fixed in 95a19e6, the squash commit of #3 on main.

Already fixed in 95a19e6, the squash commit of https://code.j4k.dev/j4k-oss/perplexity-agent-mcp/pulls/3 on main.

jercik marked this conversation as resolved

jercik commented

2026-10-22 17:52:51 +00:00

Replying to review 01M5JBAZ7W4NBGQYE07XQT116Y (summary #178087, head f32e196d)

Both findings (Node minimum 01M5JBDCWK57HHES7WBV3S2JHP, model-selection copy and prompt source pointers 01M5JBE124AKC1DFK5DWMK1JHT) are valid, concern README text this PR does not touch, and are already fixed on main in 95a19e6 (#3). This branch was cut before that PR merged, so the review ran on the old text.

> Replying to review `01M5JBAZ7W4NBGQYE07XQT116Y` (summary #178087, head f32e196d) Both findings (Node minimum `01M5JBDCWK57HHES7WBV3S2JHP`, model-selection copy and prompt source pointers `01M5JBE124AKC1DFK5DWMK1JHT`) are valid, concern README text this PR does not touch, and are already fixed on `main` in 95a19e6 (https://code.j4k.dev/j4k-oss/perplexity-agent-mcp/pulls/3). This branch was cut before that PR merged, so the review ran on the old text.

jercik commented

2026-10-22 17:52:52 +00:00

Replying to review comment #178088

Already fixed on main in 95a19e6 (#3). This branch was cut before that PR merged, so the review ran on the old README.

> Replying to review comment #178088 Already fixed on `main` in 95a19e6 (https://code.j4k.dev/j4k-oss/perplexity-agent-mcp/pulls/3). This branch was cut before that PR merged, so the review ran on the old README.

jercik merged commit 48a390df1c into main

2026-10-22 17:53:22 +00:00

jercik deleted branch docs/remove-empty-testing-heading

2026-10-22 17:53:22 +00:00

jercik referenced this pull request from a commit

2026-10-22 17:53:23 +00:00

docs: remove the empty testing heading from the README (#4)

Sign in to join this conversation.

No reviewers

No labels

No milestone