docs: say why the @j4k-oss registry mapping is required #8

Merged

jercik merged 1 commit from docs/npm-scope-ownership into main 2026-10-23 07:15:48 +00:00

Conversation 2 Commits 1 Files changed 2 +3 -3

jercik commented 2026-10-23 07:09:31 +00:00

Owner

• Copy link
• Copy Markdown

The @j4k-oss scope on npmjs is now ours and holds no packages, so the README no longer calls its owner unconfirmed or says npm could fetch another owner's package. The registry mapping is still required, because without it npm looks on npmjs, finds nothing, and fails with a 404. The README also calls the unscoped fta-check deprecated instead of frozen.

AGENTS.md is regenerated from align 9.0.6. The only change is the same reason in the repoq rule.

🤖 Generated with Claude Code

The `@j4k-oss` scope on npmjs is now ours and holds no packages, so the README no longer calls its owner unconfirmed or says `npm` could fetch another owner's package. The registry mapping is still required, because without it `npm` looks on npmjs, finds nothing, and fails with a 404. The README also calls the unscoped `fta-check` deprecated instead of frozen. `AGENTS.md` is regenerated from align 9.0.6. The only change is the same reason in the repoq rule. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

jercik added 1 commit 2026-10-23 07:09:31 +00:00

docs: say why the @j4k-oss registry mapping is required ... 8b84a73041

The @j4k-oss scope on npmjs is now ours and holds no packages. The
registry mapping is still required because every @j4k-oss package exists
only on the Forge: without it, npm looks on npmjs, finds nothing, and
fails with a 404. The unscoped npmjs packages are deprecated.

Regenerate AGENTS.md from align 9.0.6 for the matching repoq rule.

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

forgejo-actions commented 2026-10-23 07:14:22 +00:00

• Copy link
• Copy Markdown

Review 01M5KSFXVBXKDYK0G7795RAT83 — head 8b84a73041a195dd1182345d887bba8d92cc1dad

Review — j4k-oss/fta-check @ 8d49101265

Scope: diff against base tree 9b0a98a7e607
Status: dispatched — coverage complete (9/9 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 (1)

low — The output example labels an estimated bug count as a probability

• claim: 01M5KSK6J5CRWT4NKEGYVGEBNB
• anchor: README.md (snippet)

   - High bug probability (1.51) - split complex logic for better testing

• lens: writing-quality · arm: default
• verdicts: 1 valid / 0 invalid / 0 uncertain
  • pass 01M5KSKXYAYZBSV9MVP3FB0YRV · valid: The anchor is an exact grounded match: the README's sample output reads 'High bug probability (1.51)'. A probability cannot exceed 1, so that wording is wrong on its own face, without needing any other evidence. The reviewer also reports that the same example shows 'Estimated bugs: 1.51' and that src/lib/fta-report.ts builds both the 'estimated bugs' label (formatViolation) and the 'probability' suggestion (generateSuggestions) from the same result.halstead.bugs field, with no conversion. That trace hangs together and matches the standard Halstead metric (B = V/3000), which estimates a count of delivered bugs, not a probability. The batch shows no safeguard, scale, or documented conversion that would make 'probability' correct. Using two terms for one number breaks the human-facing writing skill's 'one term per concept' rule and its Honesty rule against wording that widens a claim. The proposed fix is a small in-place relabel ('High estimated bug count (1.51)') that adds no inventory and drops no meaning. Making the same wording change in the report generator keeps the README consistent with the real output. Low severity is right.
• disposition: none

Readers interpreting the analysis are given incompatible meanings for the same number: an estimated count and a probability. A probability cannot exceed 1, so calling 1.51 a probability obscures what the metric actually measures.

The example first says Estimated bugs: 1.51, then calls that value High bug probability (1.51). In src/lib/fta-report.ts, formatViolation labels h.bugs as estimated bugs, and generateSuggestions uses that same result.halstead.bugs field in the probability message. This is a terminology mismatch in the actual output as well as its documentation.

Change the recommendation to High estimated bug count (1.51) - split complex logic for better testing, and use the same terminology in the report generator. This preserves the reader's task of interpreting the recommendation and its numeric evidence without adding another definition or inventory. It follows the human-facing writing skill's requirements to use one term per concept and avoid simplifications that widen a claim.

I read the full README, traced printReport, formatViolation, and generateSuggestions in src/lib/fta-report.ts, and checked the getViolations call path. This is a static trace; I did not execute the CLI.

The decisive evidence is that both labels consume the identical halstead.bugs field, with no conversion to a probability. A documented probability scale or conversion could refute that interpretation, but neither appears in the examined report code.

Other claims

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

Coverage

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

lens	part	arm	unit status	runs	loss
general-bug	whole	default	no-claims	1	no
writing-quality	whole	default	claims-emitted	1	no
test-trimming	whole	default	no-claims	1	no
restated-sets	whole	default	no-claims	1	no
project-docs	whole	default	no-claims	1	no
unix-cli	whole	default	no-claims	1	no
use-effect	whole	default	no-claims	1	no
module-design	whole	default	no-claims	1	no
react	whole	default	no-claims	1	no

<!-- review:summary --> **Review** `01M5KSFXVBXKDYK0G7795RAT83` — head `8b84a73041a195dd1182345d887bba8d92cc1dad` # Review — j4k-oss/fta-check @ 8d49101265ee Scope: diff against base tree `9b0a98a7e607` Status: dispatched — coverage complete (9/9 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 (1) ### low — The output example labels an estimated bug count as a probability - claim: `01M5KSK6J5CRWT4NKEGYVGEBNB` - anchor: `README.md` (snippet) ``` - High bug probability (1.51) - split complex logic for better testing ``` - lens: writing-quality · arm: default - verdicts: 1 valid / 0 invalid / 0 uncertain - pass `01M5KSKXYAYZBSV9MVP3FB0YRV` · valid: The anchor is an exact grounded match: the README's sample output reads 'High bug probability (1.51)'. A probability cannot exceed 1, so that wording is wrong on its own face, without needing any other evidence. The reviewer also reports that the same example shows 'Estimated bugs: 1.51' and that src/lib/fta-report.ts builds both the 'estimated bugs' label (formatViolation) and the 'probability' suggestion (generateSuggestions) from the same result.halstead.bugs field, with no conversion. That trace hangs together and matches the standard Halstead metric (B = V/3000), which estimates a count of delivered bugs, not a probability. The batch shows no safeguard, scale, or documented conversion that would make 'probability' correct. Using two terms for one number breaks the human-facing writing skill's 'one term per concept' rule and its Honesty rule against wording that widens a claim. The proposed fix is a small in-place relabel ('High estimated bug count (1.51)') that adds no inventory and drops no meaning. Making the same wording change in the report generator keeps the README consistent with the real output. Low severity is right. - disposition: none > Readers interpreting the analysis are given incompatible meanings for the same number: an estimated count and a probability. A probability cannot exceed 1, so calling 1.51 a probability obscures what the metric actually measures. > > The example first says `Estimated bugs: 1.51`, then calls that value `High bug probability (1.51)`. In `src/lib/fta-report.ts`, `formatViolation` labels `h.bugs` as estimated bugs, and `generateSuggestions` uses that same `result.halstead.bugs` field in the probability message. This is a terminology mismatch in the actual output as well as its documentation. > > Change the recommendation to `High estimated bug count (1.51) - split complex logic for better testing`, and use the same terminology in the report generator. This preserves the reader's task of interpreting the recommendation and its numeric evidence without adding another definition or inventory. It follows the human-facing writing skill's requirements to use one term per concept and avoid simplifications that widen a claim. > > I read the full README, traced `printReport`, `formatViolation`, and `generateSuggestions` in `src/lib/fta-report.ts`, and checked the `getViolations` call path. This is a static trace; I did not execute the CLI. > > The decisive evidence is that both labels consume the identical `halstead.bugs` field, with no conversion to a probability. A documented probability scale or conversion could refute that interpretation, but neither appears in the examined report code. ## Other claims - grounding-pending (0) - ungrounded (0) - rejected (0) - duplicate-of (0) - unadjudicated (0) ## Coverage Coverage pass: 01M5KSFXYFHK49T91NY34W50XP Accounting: complete Slot health: healthy | lens | part | arm | unit status | runs | loss | | --- | --- | --- | --- | --- | --- | | general-bug | whole | default | no-claims | 1 | no | | writing-quality | whole | default | claims-emitted | 1 | no | | test-trimming | whole | default | no-claims | 1 | no | | restated-sets | whole | default | no-claims | 1 | no | | project-docs | whole | default | no-claims | 1 | no | | unix-cli | whole | default | no-claims | 1 | no | | use-effect | whole | default | no-claims | 1 | no | | module-design | whole | default | no-claims | 1 | no | | react | whole | default | no-claims | 1 | no |

🚀 1

jercik merged commit dabcce611d into main 2026-10-23 07:15:48 +00:00

jercik deleted branch docs/npm-scope-ownership 2026-10-23 07:15:48 +00:00

jercik referenced this pull request from a commit 2026-10-23 07:15:48 +00:00

docs: say why the `@j4k-oss` registry mapping is required (#8)

jercik referenced this pull request 2026-10-23 08:58:03 +00:00

fix: the bug hint should call the Halstead estimate a count, not a probability #9

jercik commented 2026-10-23 09:02:46 +00:00

Author

Owner

• Copy link
• Copy Markdown

Replying to review 01M5KSFXVBXKDYK0G7795RAT83 (summary #179008, head 8b84a730)

The finding is valid, and it sits in README text this PR did not change. The README sample matched the CLI, so the CLI's label was the error: halstead.bugs is FTA's volume / 3000 (crates/fta/src/halstead/mod.rs in fta v3.0.0, the fta-cli release installed here), a count that passes 1 on large files. On a generated file the built CLI printed Estimated bugs: 35.31 next to High bug probability (35.31).

Fixed in #9, merged as a627f7d: the hint in src/lib/fta-report.ts now reads High estimated bug count, and the README sample follows.

> Replying to review `01M5KSFXVBXKDYK0G7795RAT83` (summary #179008, head 8b84a730) The finding is valid, and it sits in README text this PR did not change. The README sample matched the CLI, so the CLI's label was the error: `halstead.bugs` is FTA's `volume / 3000` (`crates/fta/src/halstead/mod.rs` in fta v3.0.0, the `fta-cli` release installed here), a count that passes 1 on large files. On a generated file the built CLI printed `Estimated bugs: 35.31` next to `High bug probability (35.31)`. Fixed in https://code.j4k.dev/j4k-oss/fta-check/pulls/9, merged as a627f7d: the hint in `src/lib/fta-report.ts` now reads `High estimated bug count`, and the README sample follows.

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

j4k-oss/fta-check!8

No description provided.