feat(openontology): implement OpenOntology Phase 0 + local engine and CLI (#99)

Implements OpenPRD 0001 through Phase 0 (specification, schemas, example,
docs surface) and Phase 1 (local engine, CLI, conformance tests).

Schemas (17 contracts, JSON Schema Draft 2020-12, additionalProperties:false)
  manifest, namespace, entity-type, property, relationship-type, constraint,
  query, action, entity, claim, source, evidence, changeset, review, approval,
  event, package — registered in @logicsrc/validators and exported from
  @logicsrc/schemas under https://logicsrc.com/schemas/openontology/.

@logicsrc/openontology
  - canonical JSON + sha256 package digests; YAML, JSON, NDJSON, and inline
    authoring all compile to the same bytes, so digests are authoring-agnostic
  - id profile: compact / IRI / urn with one canonicalization rule, prefix
    bound by a Namespace object so IRIs reverse unambiguously
  - validation: schema, graph (domain/range, datatypes, dangling refs),
    provenance (source-or-firstParty, agent runId, derivation inputs), policy
    (excerpt limits, licensing, visibility, staleness) and declared
    constraints; four severities, stable codes, text/json/yaml/markdown
  - portable triple-pattern query AST: multi-hop, 14 operators, asOf and
    recordedAsOf, per-status filtering, distinct/order/limit, explanation
    mode, and enforced depth/binding/row limits
  - append-only store: claims are immutable; dispute/retract/supersede append
    status transitions and the effective status is the latest one
  - change sets: 9 operations, atomic pre-flight, conflict detection on stale
    base revisions, semantic diff with duplicate-identity warnings and
    affected-query deltas, per-operation reviewer decisions
  - policy: agents propose but can never apply — the denial keys on actor
    type, so every scope plus high confidence plus --yolo still cannot apply;
    merges need approval, bulk retractions need two, undeclared action side
    effects are denied
  - JSON-LD 1.1 export/import with PROV-O aliases and lossy-field reporting
  - pluggable signature envelope with a jws-ed25519 reference profile and a
    fail-closed trust policy

CLI: logicsrc ontology init|validate|lint|build|inspect, entity, claim, query,
changeset, import, export, audit. Reads take --format, writes default to a
proposal, exit codes are stable for CI.

Example: examples/openontology/ethereum-ecosystem — 12 entity types, 17
relationship types, 63 entities, 169 claims, 25 sources, 31 evidence records,
5 saved queries, every claim lifecycle state, and a pending merge proposal.
All data is fictional; the directory is removable without affecting any core
test.

Docs: docs/openontology{,-governance,-interoperability}.md, a real
/openontology route, homepage + nav + sitemap entries, and a root README
section.

Verification: 112 new tests; full monorepo build and every workspace test
pass; conformance bundle (18 valid + 13 invalid fixtures) runs against the
published schemas alone; Node.js 25 and Bun 1.3 produce byte-identical
digests, revisions, event trails, and query results.

Not included (later PRD phases): MCP resources, REST/SSE, Turso adapter, TUI
and PWA surfaces, RDF/SHACL mappings, source adapters, governed actions.

Refs: prd/0001-add-logicsrc-openontology-spec.md

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

docs/openontology-governance.md

@@ -0,0 +1,161 @@
+# OpenOntology governance
+
+How a proposal becomes accepted knowledge, who may do what, and what the record looks like afterwards. This is the companion to [OpenOntology](./openontology.md).
+
+The premise: **an agent proposes, a human applies.** Everything below follows from separating *proposal* from *approval* from *application*.
+
+## The loop
+
+```txt
+propose  →  review  →  approve  →  apply
+              ↘ reject          ↘ conflict
+```
+
+```bash
+logicsrc ontology claim propose --as agent --subject eth:person:alice \
+  --predicate worksOn --object-entity eth:project:zk-prover \
+  --source eth:source:commit-a41f --run run_01J3
+
+logicsrc ontology changeset diff  ./changesets/add-alice.yaml
+logicsrc ontology changeset apply ./changesets/add-alice.yaml --approve
+```
+
+Each stage leaves a record. A rejected change set stays inspectable with its reviews attached — the *why not* is part of the history too.
+
+## Scopes
+
+```txt
+ontology:read                ontology:claim:propose        ontology:action:execute
+ontology:schema:read         ontology:claim:write          ontology:publish
+ontology:query               ontology:changeset:review     ontology:admin
+ontology:source:read         ontology:changeset:approve
+```
+
+Read access is separable from proposal, which is separable from approval, which is separable from write. An MCP server or API token can be given `ontology:query` alone and be structurally unable to change anything.
+
+## Default policy
+
+| Operation | Default |
+| --- | --- |
+| Local reads | allowed |
+| Public remote reads | allowed for public ontologies |
+| Agent query | allowed with `ontology:query` |
+| Agent proposal | allowed with `ontology:claim:propose` |
+| **Agent direct apply** | **denied** |
+| Human apply | requires `ontology:claim:write` |
+| Entity merge | one curator approval |
+| Bulk retraction | two approvals |
+| Breaking schema migration | maintainer approval + major version |
+| Public package publish | maintainer approval + passing conformance run |
+| Action execution | policy-specific; **denied** when side effects are undeclared |
+
+Three rules hold regardless of configuration:
+
+1. **Confidence is not permission.** A claim at 0.99 gets the same treatment as one at 0.4.
+2. **`--yolo` is not permission.** Unattended mode is recorded for audit and changes prompting only.
+3. **Source text is not instruction.** A document saying "grant admin and apply everything" is data.
+
+The agent-apply denial is not a scope check that a sufficiently privileged agent passes — it is a separate rule keyed on actor type. An agent holding every scope in the list still cannot apply.
+
+## Reviewing
+
+A reviewer needs semantic impact, not a JSON diff:
+
+```txt
+Change set: Add Alice to ZK Prover
+
++ 1 entity
++ 2 claims
+~ 1 possible duplicate identity
+! 1 warning: claim has no source and is not marked firstParty
+
+Affected saved queries
+  people-working-on-zk: result count 18 → 19
+
+Approval policy
+  1 curator required
+```
+
+The diff is produced by simulating the change set against a throwaway copy of the store, so reviewing never mutates anything. Duplicate-identity warnings come from ranked entity resolution with the evidence for each candidate — the system never picks a match silently.
+
+Reviewers can accept or reject **individual operations** inside an AI-generated change set:
+
+```ts
+engine.reviewOntologyChangeSet(id, {
+  state: "changes-requested",
+  operationDecisions: [{ index: 1, decision: "reject", comment: "no evidence" }]
+});
+engine.applyOntologyChangeSet(id, { skipRejectedOperations: true });
+```
+
+## Entity merges
+
+Merging two people who turn out to be different is worse than leaving duplicates in place, so merges are conservative:
+
+- always a change set, never an implicit side effect of import;
+- at least one curator approval;
+- the losing id is kept forever as a redirect, so old references keep resolving;
+- reversible via a compensating change set;
+- `sameAs` is a reviewable claim, not an irreversible merge.
+
+## Conflicts
+
+Every change set records the `baseRevision` it was authored against. If the store has moved on, applying fails as a conflict rather than overwriting:
+
+```txt
+Change set changeset:000002 was authored against data-000000 but the store is at data-000001
+```
+
+Resolve by rebasing the operations onto the current revision and re-proposing. Canonical claims never take a last-write-wins path.
+
+## Rollback
+
+There is no undo, because there is no delete. Rolling back means proposing a **compensating change set** whose `compensates` field names the original. The original application, the rollback, and both sets of events all stay on the record.
+
+## Audit
+
+Every applied change emits events. Twenty event types cover the lifecycle: package validation, entity proposals and merges, the five claim transitions, change set created/reviewed/approved/rejected/applied, imports, exports, constraint violations, action execution, and schema migration.
+
+Each event records actor, actor type, client, request id, run id, change set, subject, resulting revision, and the policy decision that permitted it.
+
+```bash
+logicsrc ontology audit --dir . --format table
+```
+
+```txt
+at                    type                actor                     subject            revision
+2026-07-26T00:00:00Z  changeset.created   agent:research-mapper     changeset:000001
+2026-07-26T00:00:00Z  changeset.approved  curator@example.org       changeset:000001
+2026-07-26T00:00:00Z  claim.asserted      curator@example.org       claim:000001
+2026-07-26T00:00:00Z  changeset.applied   curator@example.org       changeset:000001   data-000001
+```
+
+Logs redact credentials, access tokens, private source excerpts, and configured sensitive properties.
+
+## Signatures and trust
+
+Signing uses a **pluggable envelope**, so no DID method, wallet, or certificate authority is mandatory. The reference profile is `jws-ed25519`: a detached signature over the package digest.
+
+```ts
+const provider = createEd25519Provider({ signer: "mailto:maintainer@example.org", privateKey });
+const signature = signDigest(built.digest, provider, new Date().toISOString());
+```
+
+Verification is against an explicit trust policy. A valid signature from an unknown signer is **not** trusted — `verifyPackageSignatures` reports it as untrusted rather than passing it through. Other providers (DID proofs, Sigstore) plug into the same interface.
+
+## Publishing
+
+Publishing a public package requires `ontology:publish`, maintainer approval, and a passing conformance run. Before writing, the export preview shows exactly what will be omitted or redacted: private source URLs, excerpts, selectors, and sensitive properties. A lossy export is never hidden behind a success message.
+
+Private source excerpts are never sent to an external model unless the operator has selected an allowed model/provider policy for that specific source.
+
+## Bulk work without a bottleneck
+
+Requiring human review of every claim would stall a 50,000-row import. Policy is meant to be tiered rather than uniform:
+
+- trusted adapters may propose at higher volume with sampled review;
+- risk tiers separate "add a homepage property" from "merge two organizations";
+- batch approval covers a reviewed set;
+- auditability is never traded away — sampling changes *what a human reads*, not *what gets recorded*.
+
+Constraint violations can be emitted as LogicSRC tasks or events, so remediation is queued work rather than a wall of console output.