* OpenErrand 0.1: an errand on a website with no API, with the human steps kept human
docs/openerrand.md mints OpenErrand: one JSON file per errand (register an
account, download a transcript) naming the site, the inputs with a
sensitivity class and ordered sources (document, vault, prompt, generate,
derive, candidate, literal), field rules matched by id then label, page and
wait steps, five human gates a runner never performs (declare,
identity-proofing, code, mail, captcha), outcomes, the never-retried shared
secret, vault and download outputs, hand-off cards that may name only public
inputs, the publisher index at /.well-known/openerrand.json, and thirteen
runner rules. The worked example is the MyFTB business registration that
cli-tools `ftb` performs (profullstack/cli-tools#125), with no personal data.
- @logicsrc/schemas: openerrand + openerrand-index schemas and fixtures
- @logicsrc/validators: semantic checks (references, templates, no personal
or secret input on a card) and tests that validate the spec's own examples
- logicsrc-web: registry entry (process family), /openerrand landing page,
the example and the index served as static files, contract tests
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* OpenErrand: hand-off cards stay on the surface that owns the data
Anthony's ruling: tax and finance data never touches a social or promotion
tool, and nothing is sent to a CPA or preparer.
- Hand-off cards are delivered only on the surface that owns the errand's
data (for a tax or finance errand, the principal's finance app through its
CLI, PWA, MCP server or API, such as CoinPay, or the runner's terminal),
never a social, promotion or third-party posting service, and never to
anyone but the principal. A card for an errand with personal or secret
inputs does not leave that surface. Runner rule 9 says the same.
- The run record and the sample run name the card by an opaque id
(pin-letter/7f3k2q) instead of a mynaposter.com URL; the myna mention is gone.
- `principal: represented` no longer cites a preparer with a power of attorney.
- The FTB card's last step no longer suggests sending the PIN to someone else.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* OpenErrand: user-agent rule, captcha solver policy, reference runner note
Anthony's answers on #227 ("go with your recommendations"):
- Rule 11: a runner may run headless with a normal desktop browser user agent
(dropping HeadlessChrome) and nothing more: no fingerprint spoofing beyond
the UA string, no stealth plugins, no solving or evading a bot challenge.
A challenge the browser completes itself is a wait step; any other is a
captcha gate.
- Captcha solvers: new site.sector and captcha step `solver`
(forbidden by default | allowed). Never allowed on government, tax,
financial, healthcare or identity-provider sites, nor on any errand with a
declare or identity-proofing step or a secret input; elsewhere only when the
file says so, with every use logged. The validator rejects `allowed` in the
forbidden set or without a stated sector; six new tests. The FTB example
states sector "tax".
- Reference runner: @logicsrc/openerrand / `logicsrc errand run`, marked in
progress; ftb stays the runner the example was taken from.
- Name stays OpenErrand; family stays Agents and process.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* OpenErrand reference runner: @logicsrc/openerrand and logicsrc errand
Ship the runner docs/openerrand.md promised. `logicsrc errand run <file>`
reads an OpenErrand 0.1 file, validates it with @logicsrc/validators, and
drives headless Chrome through it under the spec's thirteen rules;
`errand validate` shows what a file will ask of you and `errand status`
shows the last run of each errand, its card and any lockout.
The engine is generalised from cli-tools `ftb` (PR #125) with no dependency
on cli-tools: the CDP client and Chrome finder from wcag.ts, the page reader,
native-setter fill and forward-button picker from ftb-run.ts, and the rule
matcher, throttle and outcome logic from ftb.ts, all now driven by the file.
- Inputs: document (an extractor hook; the one shipped runs a local command
that reads JSON requests and prints records), vault (teams or OpenCreds),
prompt (no echo for secrets), generate, derive, candidate, literal.
`--input name=value` wins. Shared-secret candidates are ranked as the spec
says, one is submitted, and a rejection lists the others for --candidate.
- Rules: id before label, step rules first, choices before text, an id match
final, an unmatched required field stops the run naming it.
- Gates: declare only with --declare after the values are shown; identity
proofing never touched (URL only) and handed over or stopped on; code from
the terminal or a code file, used once, a wrong code waits for the next;
mail ends the run waiting with the card; captcha is the person's, and a
CaptchaSolver interface is called only where the spec permits (no solver is
bundled); wait steps are polled, never solved.
- Throttle: 2 runs per errand and account in 30 minutes, 4 a day, 2 minutes
between runs on a site, lockouts from metadata.lockout or a default, held
per site and account, never lifted by --force.
- Outputs: credentials written before success to a teams vault by pull,
merge, push (metadata.vault or --vault), else a 0600 file said aloud;
downloads type-checked and never overwritten with different bytes; cards
only in the local run record.
- The user agent is Chrome's own with HeadlessChrome replaced, given at
launch: a CDP override did not reach a navigation the page's own script
started, which is exactly the proof-of-work interstitial case.
Tests: 85 in the package (rule engine, inputs, gates, throttle, outcomes,
captcha gating, vaults, outputs, commands) including an integration test
that runs the published FTB example unchanged in real headless Chrome
against a local HTTPS fake site (Chrome maps webapp.ftb.ca.gov to it and
every other host to NOTFOUND; all data fictional), and 2 in the CLI.
CLI 0.6.0 -> 0.7.0; @logicsrc/schemas and @logicsrc/validators 0.3.0 ->
0.4.0 (the OpenErrand schemas, and the vocabularies now exported for
runners); PRD 0009; the spec's Reference runner section and the landing
page say it ships.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* OpenErrand 0.1: an errand on a website with no API, with the human steps kept human
docs/openerrand.md mints OpenErrand: one JSON file per errand (register an
account, download a transcript) naming the site, the inputs with a
sensitivity class and ordered sources (document, vault, prompt, generate,
derive, candidate, literal), field rules matched by id then label, page and
wait steps, five human gates a runner never performs (declare,
identity-proofing, code, mail, captcha), outcomes, the never-retried shared
secret, vault and download outputs, hand-off cards that may name only public
inputs, the publisher index at /.well-known/openerrand.json, and thirteen
runner rules. The worked example is the MyFTB business registration that
cli-tools `ftb` performs (profullstack/cli-tools#125), with no personal data.
- @logicsrc/schemas: openerrand + openerrand-index schemas and fixtures
- @logicsrc/validators: semantic checks (references, templates, no personal
or secret input on a card) and tests that validate the spec's own examples
- logicsrc-web: registry entry (process family), /openerrand landing page,
the example and the index served as static files, contract tests
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* OpenErrand: hand-off cards stay on the surface that owns the data
Anthony's ruling: tax and finance data never touches a social or promotion
tool, and nothing is sent to a CPA or preparer.
- Hand-off cards are delivered only on the surface that owns the errand's
data (for a tax or finance errand, the principal's finance app through its
CLI, PWA, MCP server or API, such as CoinPay, or the runner's terminal),
never a social, promotion or third-party posting service, and never to
anyone but the principal. A card for an errand with personal or secret
inputs does not leave that surface. Runner rule 9 says the same.
- The run record and the sample run name the card by an opaque id
(pin-letter/7f3k2q) instead of a mynaposter.com URL; the myna mention is gone.
- `principal: represented` no longer cites a preparer with a power of attorney.
- The FTB card's last step no longer suggests sending the PIN to someone else.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* OpenErrand: user-agent rule, captcha solver policy, reference runner note
Anthony's answers on #227 ("go with your recommendations"):
- Rule 11: a runner may run headless with a normal desktop browser user agent
(dropping HeadlessChrome) and nothing more: no fingerprint spoofing beyond
the UA string, no stealth plugins, no solving or evading a bot challenge.
A challenge the browser completes itself is a wait step; any other is a
captcha gate.
- Captcha solvers: new site.sector and captcha step `solver`
(forbidden by default | allowed). Never allowed on government, tax,
financial, healthcare or identity-provider sites, nor on any errand with a
declare or identity-proofing step or a secret input; elsewhere only when the
file says so, with every use logged. The validator rejects `allowed` in the
forbidden set or without a stated sector; six new tests. The FTB example
states sector "tax".
- Reference runner: @logicsrc/openerrand / `logicsrc errand run`, marked in
progress; ftb stays the runner the example was taken from.
- Name stays OpenErrand; family stays Agents and process.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
PR 177 shipped a second OpenFleet under the same slug: a published listing of OpenAgent profiles and ipfile swarms with CoinPay rental offers. Anthony ruled that OpenFleet means the human-controlled fleet and the record of who spawned whom, so the rental contract is renamed OpenRental (slug openrental, catalogs family, group noun listing): docs/openrental.md, logicsrc-openrental.schema.json with type logicsrc.openrental and scope kind listing, fixtures/openrental, createOpenRental and OpenRental* types in the SDK, the openrental validator kind. Minor bumps because an export moved: @logicsrc/schemas 0.2.0, @logicsrc/validators 0.2.0, @logicsrc/sdk 0.2.0. The discovery contract test now covers openfleet, openrental and openwall, one per family, and accepts a landing-page link in llms.txt.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RZV4zJ2pDZLNN3kE5jFCmV
* feat: add OpenFleet membership and CoinPay rental contracts
* Propose OpenWall broadcasts and direct messaging contracts
* release: prepare OpenFleet and OpenWall public contracts
* fix: use tested npm for compatible CLI installs
@logicsrc/opencontext could not be installed from npm. Three defects, each of
which alone breaks a published tarball:
1. opencontext depended on "@logicsrc/validators": "file:../validators". A
file: specifier is unresolvable for anyone installing from the registry, so
`npm install @logicsrc/opencontext` failed outright.
2. validators imported all 50 schemas by relative path across the repository
("../../schemas/schemas/*.json"). That resolves inside the monorepo and
escapes the package once published, so an installed validators could not
load a single schema. Now imported through @logicsrc/schemas package
exports, with a real dependency declared.
3. Three of those schemas — repo, pull-request, openprd-prd — had no entry in
the schemas exports map, so they were unreachable by package specifier.
Added; the map is now sorted so it stays readable as it grows.
validators also gained files/publishConfig/license so it publishes the same way
its siblings do.
Verified the way a stranger would: npm pack all three, install the tarballs
into a clean project outside the monorepo, and run the installed binary —
version, init, validate --strict (which exercises schema loading through the
package exports), and resolve --explain all succeed. Full workspace suite green.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Add the LogicSRC OpenContext specification
OpenContext is an open specification for durable, portable, permissioned,
provenance-aware context shared between humans and AI agents. It defines how
organizational knowledge is described, authorized, versioned, resolved,
audited, and handed between replaceable workers without losing institutional
state.
Follows the OpenPRD/OpenOntology pattern already in the repo: self-contained
JSON Schemas in @logicsrc/schemas, a reference implementation package, CLI
subcommands, docs, examples, and an OpenPRD record.
Schemas (8, all self-contained so a third party can fetch one file and
validate against it with no further resolution):
manifest, object, bundle, role, provenance, decision, diagnostic,
audit-event — registered in @logicsrc/validators and schemas:validate.
Reference implementation (@logicsrc/opencontext):
loader with upward manifest discovery, the full resolution pipeline,
authority/supersession, permissions, redaction, lifecycle, provenance,
deterministic digests, doctor, search, graph, history/diff, guarded writes,
audit events, and file/http/git/sqlite adapters.
CLI: all 15 specified commands, as a standalone `opencontext` binary and as
`logicsrc context`, sharing one implementation so the two cannot drift.
Design decisions worth noting:
- Supersession is declared, never inferred from version numbers. Inferring it
would hide the governance failure it represents and make
multiple-active-versions and duplicate-canonical impossible to detect.
- The bundle digest identifies the resolved context, not the moment it was
computed, so generated_at/bundle_id/digest/as_of are excluded while objects,
lifecycle states, exclusions and warnings are covered. That is what lets a
decision record cite exactly the context that produced it.
- A role's own max_classification beats an inherited one, so a ceiling on a
shared base role cannot silently cap a role deliberately granted more;
requesting several roles at once still takes the lowest, so combining roles
never escalates.
- Scope wildcards match whole dotted segments only. A trailing .* covers a
subtree; an interior * matches exactly one segment. Substring matching here
would be an access-control bug.
- --include narrows an existing scope and is applied after it, never merged
into it, so a request can never widen what a role holds.
Verified: 226 tests across core primitives, permissions/redaction, the
resolution pipeline, security, the published conformance fixtures (13 valid,
35 invalid, 8 resolution scenarios), project behaviour, and the five shipped
examples — which are held to --strict and a 100% health score. Benchmarks meet
every published budget (resolve 1,000 objects in ~33ms against a 2s target).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* 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>
* Advance the logicsrc-mcp next-PRD-id assertion to 0004
standards.test.ts asserts prd_next_id against the live prd/ directory, so
adding PRD 0003 makes the next free id 0004. The test's own comment
anticipates this: "advances with every PRD added".
Caught by CI, not locally — the earlier verification ran per-package tests for
the packages this branch touches, and logicsrc-mcp is coupled to the PRD
directory without importing from it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
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>
AgentGit is a thin, DID-gated source-collaboration layer over a backend
forge (default Forgejo at git.profullstack.com, BBS-members-only) — not a
new git host. M1 implements the contract and engines:
- forge/adapter.ts: ForgeAdapter interface (only forge-specific surface)
- forge/forgejo.ts: ForgejoAdapter over Forgejo/Gitea REST v1 (injectable
fetch, typed errors), incl. ensureUser for member provisioning
- access.ts: gateAccess DID membership gate (owner/role/visibility)
- merge-policy.ts: evaluateMergePolicy pure engine (reviews, reputation
floor, checks, escrow, merge method, agent-merge toggle)
- service.ts: AgentGitService ties gate + policy to the adapter; refuses
policy-failing merges; provisionMember hook for AgentBBS
- schemas: logicsrc-repo + logicsrc-pull-request, registered in
@logicsrc/validators with fixtures
- docs/agentgit.md spec; plugin wired into root build (default/disabled)
27 vitest tests pass; full monorepo build green.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Add AgentAd ad schemas as a LogicSRC primitive
AgentAd is a disclosed, agent-readable advertising contract for CLI tools
and AI agents. LogicSRC owns the canonical schemas; cl1s.tech is the
reference network built on them.
- packages/schemas: agentad-{ad,placement,ad-request,ad-response,
impression,click,campaign} schemas (id under schemas.logicsrc.com) +
ad/placement fixtures, exported from @logicsrc/schemas
- packages/validators: register the 7 agentad kinds, wire fixture
validation, add tests (disclosure.sponsored must be true)
- docs/agentad.md: the AgentAd spec
- README: list AgentAd under v1 priorities
Validators build clean; all fixtures validate; vitest 4/4 green.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Prepare @logicsrc/schemas for npm publish
Add license, repository, homepage, keywords, publishConfig (public),
and a package README covering both the logicsrc-* core schemas and the
agentad-* family.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
