Add the LogicSRC OpenCreds specification (#140)

* Add the LogicSRC OpenCreds specification

Leaving a password manager means writing every secret you own to disk in
the clear, and losing whatever the spreadsheet had no column for. A CSV
is plaintext by construction, lossy by omission, and carries no
integrity: nothing in it says which rows were meant to be there, so a
truncated import looks exactly like a complete one.

The same gap showed up inside LogicSRC. `logicsrc credentials` moves
.env secrets and SSH keys through end-to-end-encrypted team vaults, but
it can only model a key/value pair. A card, a passport, a login with a
TOTP seed, or an OAuth account with a refresh token are all things
people already keep in a vault, and none of them are a key/value pair.

OpenCreds defines three things: the item, the vault, and the database.

- Six item types (login, card, identity, note, key, account) as one
  record with a type and a named field group, so everything the user
  typed lives in a single encrypted blob. Codes 1-4 match MarkSyncr's
  deployed vault and are not renumbered; compatibility is cheaper than
  elegance.
- AES-256-GCM over that record with the item id bound as AAD. Without
  it, anyone with storage write access could move a low-value login's
  ciphertext into a high-value row and watch what the user does next.
- A key hierarchy where the user key is random, not derived, so a
  password change re-wraps 32 bytes rather than re-encrypting a vault.
  The auth hash comes out of a different HKDF label than the wrap key,
  which is what lets it reach a server at all.
- A portable .opencreds file, encrypted by default, whose header is the
  AAD over the payload -- so the manifest is authenticated by the same
  tag as the data and a truncated import fails rather than reporting
  success. The plaintext form exists because people move to products
  that read nothing else; it is opt-in, confirmed, 0600, and labelled
  "protected": false in its own header.

Namespaces are carried as data, not fixed by the spec: labels are
compiled into every ciphertext a vault has written, so editing one does
not migrate a vault, it makes it undecryptable. MarkSyncr's deployed
vault is conformant by declaring `marksyncr`.

Ships: prd/0004, nine spec pages under docs/opencreds/, six JSON
Schemas, the @logicsrc/opencreds reference implementation with CSV
importers for five products, `logicsrc vault` and the standalone
`opencreds` binary, and the spec page at logicsrc.com/opencreds.

`vault` rather than `creds` because `creds` is already an alias of
`logicsrc credentials`, and the two are different: one moves a pair
between providers, the other stores a record.

@logicsrc/validators now registers every schema by $id before
compiling, so the database schema can $ref the item and manifest
schemas rather than restating them.

120 tests, including CLI end-to-end coverage of the masking rules,
exit codes, and the manifest-mismatch path.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QRQrfuwuYKKV5UB9kLHuX5

* Make the OpenCreds conformance claim executable

The conformance page described a fixture suite and an `opencreds
conformance` command that did not exist. A specification that documents
a conformance surface it cannot run is a specification nobody can hold
to, including us.

`opencreds conformance` now runs the requirement list as code -- one
check per C-number, carrying its own id and level -- and emits the
report shape the spec publishes. It exits 2 when a MUST does not pass,
so it can gate CI directly. The reference implementation reports 29
passed, 0 failed, 1 skipped; the skip is C19, because key management for
the team profile lives in @logicsrc/plugin-credential-sharing rather
than in this package, and a skipped MAY does not affect conformance.

Fixtures are generated (`--emit-fixtures <dir>`) rather than
hand-written. A vector produced by an implementation and then verified
by it is worth more than a JSON file someone typed: the typed file
drifts silently when the format moves, and the generated one cannot.
Fourteen files, including an invalid/ set every conforming reader must
reject -- a wrong field group, a weak KDF, an unregistered namespace, a
short payload and a tampered manifest.

The CLI requirements stay with the end-to-end tests that drive the real
binary through a child process; a command cannot meaningfully check its
own exit codes, and a masked value that is only masked in the library is
not masked.

conformance.md and cli.md now describe what ships.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QRQrfuwuYKKV5UB9kLHuX5

* Add @logicsrc/opencreds to the lockfile

`npm ci` refuses a lockfile that does not match package.json, and the
new workspace package plus the CLI's dependency on it were never
recorded: the worktree was bootstrapped by hardlinking node_modules
rather than installing, so npm was never asked to update the lock.

Adds the workspace link and the package entry. No dependency versions
move.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QRQrfuwuYKKV5UB9kLHuX5

* Register PRD 0004, and stop the fixtures looking like real secrets

Two CI failures, both mine.

`prd/README.md` is generated by `logicsrc prd index --write` and the
scaffold test asserts it is current, so adding a PRD without
regenerating it leaves the repo's own conformance check failing.
Regenerated. The MCP test asserts the next free PRD id against the live
prd/ directory — its comment says it advances with every PRD added — so
it moves to 0005.

ThreatCrush flagged three of the example strings: a PEM header in the
item-model docs and in the conformance fixture, and an `sk_live_`
prefixed token. All placeholders, none real, but the finding is the
scanner working. A fixture only has to exercise the field, and a
real-looking private key header or live-key prefix sitting in the tree
trains both the scanner and the people reading its output to shrug at
exactly the shape that matters. Replaced with obvious placeholders
rather than suppressing the rule.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QRQrfuwuYKKV5UB9kLHuX5

---------

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

docs/opencreds/security.md

@@ -0,0 +1,120 @@
+# OpenCreds security model
+
+## What the format protects
+
+An attacker holding **the storage** — the database, its backups, an operator's
+console, a restored snapshot — learns:
+
+- how many items a vault holds, and how many of each type;
+- when each item was created and last changed;
+- the vault's KDF parameters, salt, and wrapped keys;
+- folder ids, and folder names in implementations that store them in the clear.
+
+They do not learn any field of any item. The user key is never present in
+storage in a form the storage can open.
+
+An attacker holding **the storage and write access** additionally cannot move a
+ciphertext between rows: the item id is bound as additional authenticated data,
+so a swapped ciphertext fails to decrypt rather than showing the wrong
+credential under a trusted name.
+
+An attacker holding **the auth hash** — every one ever sent, in full — cannot
+derive the wrapping key. The two come out of the same master key under distinct
+HKDF labels.
+
+## What it does not protect
+
+**Metadata.** Item counts by type are visible by design, because the type code
+is stored in plaintext so a server can filter and paginate without decrypting.
+That means a server learns you hold forty logins and two cards. Hiding it costs
+padding and blind indexes and buys less than it appears to; the specification
+states the leak rather than obscuring it.
+
+**A weak master password.** PBKDF2 at 600,000 iterations raises the cost of a
+guess; it does not make a common password safe. Nothing in the format can.
+
+**A compromised client.** Every value is decrypted somewhere. An attacker who
+runs code in the process that holds the user key has the vault, and no format
+choice changes that.
+
+**A plaintext export.** It is exactly what it says. See below.
+
+**Deletion.** `deleted_at` is a trash bin, not an erasure. A purge removes the
+row; whether it removes the bytes is a property of the storage engine and its
+backups, not of this specification.
+
+## Deliberate decisions
+
+### The type code is plaintext
+
+So the server can paginate. The alternative — decrypting every row to answer
+"show me page 2 of the logins" — either moves the whole vault to the client on
+every read or gives the server a key. Both are worse.
+
+### Key material is base64 text
+
+Where this travels as JSON over an HTTP API, binary round-trips as an escaped
+hex string and invites encoding mistakes on exactly the values that must not be
+corrupted. Text that is wrong is visibly wrong.
+
+### One item is one blob
+
+Password history, custom fields and attachment keys all live inside the item's
+single ciphertext. That makes history encrypted by construction rather than by a
+second protected table someone can forget to protect. It costs a full rewrite of
+the item on every save, which is why history is capped — an uncapped array grows
+the ciphertext without bound.
+
+### One row per item
+
+Not one blob per vault. Two devices editing two *different* passwords at the
+same moment must not cost anyone a credential, and with a single blob the later
+write silently discards the earlier. Per-item rows with a revision make that a
+detectable conflict instead of a silent loss.
+
+### The KDF floor is enforced client-side
+
+Parameters arrive from a server. If the server is compromised, they are
+attacker-controlled, and `iterations: 1` turns captured auth hashes into a free
+offline attack. The client refuses below its own floor before deriving anything,
+and a database-backed implementation SHOULD repeat the constraint in the schema.
+
+## The plaintext export
+
+This is the most dangerous operation in the specification, and it is specified
+because the alternative is people writing worse versions of it themselves.
+
+Requirements, restated:
+
+- Never the default.
+- An explicit flag, plus a confirmation.
+- `"protected": false` in the header so tooling can identify the file.
+- Owner-only file mode where the platform has one.
+- A warning that says what it means: this file cannot be un-leaked, and every
+  password in it should be considered exposed if it is.
+
+An implementation SHOULD offer to delete the file after a successful import
+elsewhere, and MUST NOT do so automatically — the person may still need it.
+
+## Threats specific to the `team` profile
+
+Every member holding the vault key reads every item in the vault. This is a
+property of a shared symmetric key, not a gap in the implementation.
+
+Consequences worth stating in a product's own docs:
+
+- **Revocation requires rotation.** Removing a member's wrapped key stops them
+  fetching new ciphertext. It does not un-know the key they held. A member who
+  leaves means a new vault key and a re-encryption of every item.
+- **Partial sharing is a second vault.** There is no way to share three items out
+  of forty under one key. Split the vault.
+- **Granting is a client-side act.** An existing member unwraps and re-seals to
+  the new member's public key. The server can add a member to a list; it cannot
+  give them access, because it does not have the key. This is a feature, and it
+  means a grant requires an authorized member to be online.
+
+## Reporting
+
+Security issues in the specification or the reference implementation:
+`security@profullstack.com`, or the security policy published at
+`logicsrc.com/.well-known/security.txt`.