Point install docs at @logicsrc/opencontext; record the npm name collision

The unscoped `opencontext` name is already published on npm by an unrelated
third party (federicodeponte/opencontext, 2.0.0), so `npx opencontext` would
install a stranger's package. Docs now use `npx @logicsrc/opencontext`; the bin
stays named `opencontext` so the command reads as the PRD specifies once
installed.

Recorded in PRD 0003 as a blocker to resolve before any publication, along with
the fact that no @logicsrc spec package has ever been published, so there is no
existing release path to slot into.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Anthony Ettinger 2026-08-09 18:30:28 +00:00
parent ec3ed64f20
commit dc56e4c741
7 changed files with 31 additions and 17 deletions

View file

@ -183,6 +183,20 @@ that quietly diverged would become a second contract.
- **Digest churn.** A resolver bug fix that changes what is selected changes
bundle digests, which a consumer might read as tampering. Mitigated by calling
such fixes out explicitly in the changelog.
- **Blocker: the `opencontext` npm name is taken.** This PRD proposes
`opencontext` as the package name and `npx opencontext` as the install path.
That name is already published by an unrelated third party
(`federicodeponte/opencontext`, currently 2.0.0, "AI-powered company context
analysis from your terminal") — and being adjacent in subject matter makes the
confusion worse, not better. Documentation therefore ships pointing at
`npx @logicsrc/opencontext`, and the `bin` is still named `opencontext` so the
command reads as specified once installed. Resolving this needs a decision
before any publication: request a transfer, pick a different unscoped name, or
commit to the scoped package permanently.
- **No publication pipeline exists yet.** Neither `@logicsrc/openprd` nor
`@logicsrc/openontology` has ever been published to npm, so OpenContext is not
slotting into an established release path — one has to be built. Until then
the only distribution is this repository.
- **Open question.** Should interior wildcards (`customers.*.churn-risk`) remain
single-segment only, or should a future minor version add a bounded multi-
segment form? Single-segment is shipped in v1 because the alternative silently