bbs.profullstack/logicsrc

Fork 0

mirror of https://github.com/profullstack/logicsrc.git synced 2026-09-10 19:26:00 +00:00

Anthony Ettinger 7f9e493929

CI / build (push) Waiting to run

Details

test / test (push) Waiting to run

Details

Release @logicsrc/openprd 0.2.0 to npm (#145 )

Published as @logicsrc/openprd@0.2.0 — the first release of this package, and
the first carrying OpenPRD 0.3 (Tech Stack and Monetization, #144).

Two things had to change for the publish to be usable:

  - The @logicsrc/validators dependency was `file:../validators`. npm publishes
    that spec verbatim, so every install outside this monorepo would have
    failed to resolve it. It is now `^0.1.0`, which is what is on the registry;
    npm workspaces still links the local package for development, since 0.1.0
    satisfies the range.
  - Added a README. Without one the npm page reads "No README data found",
    which is a poor landing surface for the reference implementation of a
    public standard. @logicsrc/schemas already ships one.

Verified by installing 0.2.0 from the registry into an empty project: it
resolves @logicsrc/validators@0.1.0 and @logicsrc/schemas@0.1.0, and the
runtime reports OPENPRD_VERSION 0.3 with ten sections, eight for 0.2.


Claude-Session: https://claude.ai/code/session_017XRNNm6pK6nPi7rJ6bJNHu

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-09-07 05:01:33 -07:00

2.7 KiB

Raw Blame History

@logicsrc/openprd

Reference implementation of OpenPRD, a lightweight open standard for product requirements documents authored by humans or AI agents.

A repo keeps a numbered, committed collection under prd/ — one Markdown file per product decision, with YAML front-matter, a fixed set of body sections, and an enforced lifecycle. Where a change-oriented format models a change as a multi-file bundle, OpenPRD models a product decision as one numbered file you can read a year later to recover the why.

A PRD is just a file. Nothing here is required for a document to conform; this package exists to check and generate them.

Install

npm install @logicsrc/openprd

Or use it through the LogicSRC CLI, which wraps this package as logicsrc prd.

Usage

import { parsePrd, validatePrdDocument, loadPrdCollection, SECTIONS } from "@logicsrc/openprd";

const doc = parsePrd(source, "0001-expand-the-service.md");
const findings = validatePrdDocument(doc, { strict: true });

// Collection-level rules: contiguous numbering, unique ids, resolvable
// supersession links, a fresh index.
const collection = loadPrdCollection("prd");

The ten sections (OpenPRD 0.3)

Problem, Goals, Non-Goals, Users, Requirements, UX Notes, Tech Stack, Monetization, Success Metrics, Risks & Open Questions — in that order, all required. A section may be a single line such as _None._, but it may not be missing. That is what keeps every PRD skimmable and diffable.

Versioning

A document is validated against the section list its own openprd: key fixes, not against the newest version:

Version	Sections
`0.2`	eight
`0.3`	ten — adds `Tech Stack` and `Monetization` after `UX Notes`

So a 0.2 document keeps conforming. sectionsForVersion(version) exposes the rule directly.

Conformance

A document conforms when it lives at prd/<id>-<slug>.md with a four-digit id, its front-matter validates against openprd-prd.schema.json, id equals the filename's numeric prefix, and every body section for its declared version is present in order.

Everything else the validator reports is lint — an empty section, a requirement missing its priority tag, numbering that skips, a stale index, a one-sided supersession link. Findings carry stable codes (OP-C-SECTION-ORDER, OP-L-REQ-DUPLICATE, …), the file, the line, and a remediation hint. strict promotes lint to errors.

2.7 KiB Raw Blame History