feat(zotero): add local authorization lifecycle

SECURITY.md

@@ -29,6 +29,13 @@ All source artifacts, generated candidate payloads, external ontology files, mod
 8. external-source SSRF or credential leakage;
 9. model/provider compromise or unexpected retention;
 10. governance bypass from Proposed/Validated directly to Published;
-11. in-place mutation or overwrite of previously published semantic truth.
+11. in-place mutation or overwrite of previously published semantic truth;
+12. credential disclosure or endpoint interposition on provider-defined local transports that do not cryptographically authenticate or encrypt the peer channel.
 
-Security findings become tests before the related runtime capability can be marked release-ready.
+## Zotero Local API write-back boundary
+
+Zotero 10+ write authorization and mutation use the provider-defined loopback HTTP Local API. Loopback pinning, redirect rejection, and `Zotero-Server-ID` continuity checks do not encrypt `Zotero-API-Key` traffic and do not authenticate the local peer before the key is transmitted. `Zotero-Server-ID` is a database continuity/precondition coordinate, not cryptographic server authentication.
+
+A hostile same-host process capable of binding, observing, or interposing on the loopback endpoint therefore remains an unresolved credential-confidentiality threat. The currently documented Zotero Local API does not provide an HTTPS or OS-authenticated IPC write endpoint that ConceptWeave can substitute. Consequently, mock/local orchestration may be tested, but enterprise-secure live write-back remains fail closed. It may become release-eligible only if Zotero provides a protected transport or an explicit product-security/governance decision narrows the supported threat model and accepts the residual same-host risk. The detailed actor, asset, residual-risk, and release decision is maintained in `THREAT_MODEL.md`, and `docs/TRD.md` carries the same technical boundary.
+
+Security findings become tests before the related runtime capability can be marked release-ready.

THREAT_MODEL.md

@@ -0,0 +1,69 @@
+# ConceptWeave Threat Model
+
+## Scope and authority
+
+This document records product security boundaries that affect ConceptWeave semantic engineering and release eligibility. `SECURITY.md` defines baseline controls; this file names concrete actors, assets, trust assumptions, residual risks, and fail-closed decisions for implemented capabilities. Product-domain truth remains with its canonical owner. External providers and CWL sibling products are treated through explicit ports/contracts rather than copied authority.
+
+## Protected assets
+
+- immutable source snapshots, source coordinates, digests, and observation receipts;
+- semantic candidates, validation evidence, steward review receipts, and immutable semantic releases;
+- Zotero bibliographic records and reviewed write plans;
+- credentials, authorization tokens, API keys, and source-registry capability material;
+- tenant/workspace authorization context when introduced;
+- release provenance, SBOM/provenance evidence, and rollback coordinates.
+
+Credentials and authorization material must never become semantic evidence, serialized domain artifacts, logs, model prompts, test fixtures, or immutable release payloads.
+
+## Trust boundaries
+
+Source artifacts, imported ontologies, provider responses, model outputs, web-retrieved content, and external system metadata are untrusted until validated at their owning boundary. LLM proposals are non-authoritative until deterministic validation and steward publication. Source Observation accepts only bounded adapter evidence and must not turn a syntactically plausible identifier into authorization provenance. Client Consumption admits only released immutable contracts.
+
+## Primary threats
+
+1. malicious or malformed source content causing semantic poisoning, parser/resource exhaustion, or provenance confusion;
+2. model output being promoted to authority without deterministic validation and steward review;
+3. credential or source-authorization leakage across domain, evidence, log, or model boundaries;
+4. source-system mutation from discovery/validation code or hidden cross-service SQL coupling;
+5. stale, ambiguous, or mismatched source coordinates being recorded as immutable evidence;
+6. in-place mutation of published semantic truth instead of explicit supersession;
+7. tenant/workspace evidence disclosure;
+8. SSRF, DNS rebinding, unsafe redirects, or unbounded external retrieval;
+9. dependency/provider compromise or unexpected retention;
+10. write-back without reviewed before/after/rollback evidence and exact preconditions.
+
+## Zotero 10+ Local API transport boundary
+
+Zotero's documented Local API endpoint is `http://localhost:23119/api/`. Read requests are unauthenticated. Write requests require a user-granted local API key and, in Zotero 10+, the expected `Zotero-Server-ID` continuity coordinate.
+
+`Zotero-Server-ID is not cryptographic server authentication`. It identifies the Zotero database instance and supports stale/database-switch detection, but it does not authenticate the loopback peer before a request transmits `Zotero-API-Key`. Loopback pinning and redirect rejection reduce network exposure but do not encrypt HTTP traffic or provide OS-authenticated IPC.
+
+### Threat actor
+
+A hostile same-host process that can bind, observe, or interpose on the loopback endpoint is inside the unresolved threat boundary for Zotero write credentials. ConceptWeave currently has no provider-documented HTTPS or equivalent OS-authenticated IPC endpoint that can replace the Local API write path.
+
+### Current decision
+
+The Zotero adapter may be used for read-only intake and for mock/local verification of authorization and write orchestration. It must not be represented or released as enterprise-secure live write-back while confidentiality against a hostile same-host process is unproven. Live enterprise write-back therefore remains fail closed.
+
+A future release may cross this boundary only when one of the following is true:
+
+- Zotero exposes an authenticated encrypted or OS-authenticated IPC transport and ConceptWeave verifies it before transmitting a key; or
+- a product-security decision explicitly narrows the supported threat model to exclude hostile same-host observation/interposition, records the residual credential risk, and receives the required governance approval.
+
+Neither path may reinterpret `Zotero-Server-ID` as cryptographic peer authentication.
+
+## Zotero write invariants retained regardless of transport decision
+
+- local API keys stay private and non-serializable;
+- authorization is user initiated and denial/rate-limit outcomes remain fail closed;
+- server/library/item preconditions are verified before mutation;
+- database switches are surfaced as a distinct failure;
+- dry-run performs no mutation;
+- approved writes preserve exact before/after evidence, partial-failure reconciliation, and rollback coordinates;
+- attachments and bibliographic source records are not deleted by classification write-back;
+- descendant integration evidence never back-proves an unresolved predecessor contract.
+
+## Release gate
+
+A capability is not release-ready while a valid security finding lacks a deterministic test or equivalent machine-verifiable contract, while required exact-head checks are non-terminal, or while the implemented transport cannot satisfy the advertised security claim. Documentation must describe residual risk without upgrading provider guarantees by inference.