Add PRD/TSD specs and initial TRSL research + Trust Service workplans

Establishes specs/ProductRequirementsDocument.md and
specs/TechnicalSpecificationDocument.md, plus two workplans: prior-art
research for the TargetRevenueSourceLicense draft, and bootstrapping the
Trust Service reference implementation.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

workplans/TREV-WP-0001-license-prior-art-research.md

@@ -0,0 +1,131 @@
+---
+id: TREV-WP-0001
+type: workplan
+title: "TargetRevenueSourceLicense prior-art and adjacent-concept research"
+domain: infotech
+repo: target-revenue
+status: active
+owner: claude
+topic_slug: infotech
+created: "2026-07-28"
+updated: "2026-07-28"
+---
+
+# TargetRevenueSourceLicense prior-art and adjacent-concept research
+
+Research prior art and adjacent licensing/monetization concepts to ground an
+initial draft of the Target Revenue Source License (TRSL). The concept is
+already established in `spec/TargetRevenueLicenseConcept.md` and
+`specs/ProductRequirementsDocument.md`; `history/260728-InitialExploration.md`
+already surfaces several reference points (Fair Source, PolyForm
+NonCommercial, Business Source License 1.1, FSL, OSI Open Source Definition,
+SPDX `LicenseRef-` conventions, German §31/§307/§32 considerations). This
+workplan deepens and formalizes that groundwork into a research artifact
+sufficient to brief specialist legal drafting (PRD Roadmap Phase 2, MVP
+deliverable `TargetRevenueSourceLicense-Draft.md`).
+
+This workplan does **not** produce final legal text. It produces the research
+basis and an initial non-binding draft skeleton for specialist review, per
+`specs/TechnicalSpecificationDocument.md` §8 (out-of-scope reinforcement).
+
+## Survey delayed-open-source and source-available license models
+
+```task
+id: TREV-WP-0001-T01
+status: todo
+priority: high
+```
+
+Survey and compare structurally similar models: Business Source License 1.1
+(MariaDB), Functional Source License (FSL), PolyForm Noncommercial /
+PolyForm Shield, Fair Source (fair.io), Elastic License 2.0, Sentry's SSPL-
+adjacent choices, and any other revenue- or time-triggered conversion
+licenses. For each, capture: the trigger mechanism (fixed date vs. revenue vs.
+hybrid), the pre-conversion restriction scope, the automatic-conversion legal
+wording, and known criticisms or disputes. Record findings so they can be
+diffed directly against TRSL's Phase/Target/Conversion model in
+`spec/TargetRevenueLicenseConcept.md` §7, §10, §18.
+
+## Survey OSI Open Source Definition and Fair Source boundary framing
+
+```task
+id: TREV-WP-0001-T02
+status: todo
+priority: high
+```
+
+Confirm and document precisely why TRSL's pre-conversion state cannot be
+described as "Open Source" under the OSI Open Source Definition
+(field-of-endeavour non-discrimination), and how Fair Source's "source
+available with limited business-protection restriction, later converts to
+OSI-approved license" framing applies or should be adapted. Produce
+recommended terminology guardrails (source-available vs. open source vs.
+commercially licensed) for use consistently across all TRF documents.
+
+## Survey patent-grant and Future License precedent (MIT vs Apache-2.0)
+
+```task
+id: TREV-WP-0001-T03
+status: todo
+priority: medium
+```
+
+Research the practical and legal tradeoffs between MIT and Apache-2.0 as
+canonical Future Licenses, focusing on: the extent and legal certainty of any
+implied patent grant under MIT, Apache-2.0's explicit patent grant and
+patent-litigation termination clause, and precedent for offering both as
+parallel canonical options (per PRD open question 3 /
+`spec/TargetRevenueLicenseConcept.md` §24.3). Produce a recommendation on
+whether the TRSL pre-conversion phase itself needs an express patent license
+independent of the eventual Future License choice.
+
+## Survey contributor-rights instruments for dual-future licensing
+
+```task
+id: TREV-WP-0001-T04
+status: todo
+priority: medium
+```
+
+Research contributor license agreement (CLA) and copyright assignment
+patterns used by projects that must promise two future states (a restricted
+phase license plus an eventual permissive license) — e.g. how BSL/FSL-based
+projects and other dual/relicensing projects handle contributor rights.
+Compare against the Developer Certificate of Origin (DCO), and determine
+whether a DCO alone is sufficient or whether TRSL requires a broader inbound
+grant (per `history/260728-InitialExploration.md` §8 and
+`spec/TargetRevenueLicenseConcept.md` §21.4).
+
+## Survey jurisdiction-specific standard-terms constraints
+
+```task
+id: TREV-WP-0001-T05
+status: todo
+priority: medium
+```
+
+Deepen the German-law groundwork already sketched in
+`history/260728-InitialExploration.md` §10 (§31 UrhG scoped rights of use,
+§307 BGB standard-terms clarity requirement, §32 UrhG author remuneration)
+and identify whether comparable standard-terms / consumer-protection
+constraints in other jurisdictions relevant to likely early commercial users
+(e.g. US, EU generally) impose similar clarity requirements on terms such as
+"commercial use," "captured," "Development Credit," and "Conversion Event."
+Flag terms that most urgently need objective, litigation-safe definitions.
+
+## Synthesize findings into an initial TRSL draft skeleton
+
+```task
+id: TREV-WP-0001-T06
+status: todo
+priority: high
+```
+
+Using T01–T05, produce `specs/TargetRevenueSourceLicense-Draft.md`: a
+non-binding initial drafting basis (not final legal text) structuring the
+license around the components already identified in
+`spec/TargetRevenueLicenseConcept.md` §21 (permitted noncommercial use,
+commercial-use restriction, automatic Future License conversion, patent
+treatment, termination and cure, warranty/liability exclusions). Explicitly
+mark every clause requiring specialist legal review before use, per
+`spec/TargetRevenueLicenseConcept.md` §21.5.

workplans/TREV-WP-0002-trust-service-implementation-bootstrap.md

@@ -0,0 +1,126 @@
+---
+id: TREV-WP-0002
+type: workplan
+title: "Trust Service implementation bootstrap"
+domain: infotech
+repo: target-revenue
+status: active
+owner: claude
+topic_slug: infotech
+created: "2026-07-28"
+updated: "2026-07-28"
+---
+
+# Trust Service implementation bootstrap
+
+Start the reference implementation of the Trust Service (PRD Roadmap Phase 4,
+`specs/ProductRequirementsDocument.md` §11.1 item 8). The data model and
+component boundaries are already specified in
+`specs/TechnicalSpecificationDocument.md` §3 (Phase Manifest, Target Ledger
+Entry, Extension Contract, Transaction Allocation, Conversion Attestation)
+and §4 (component architecture: Phase Registry, Extension Registry, Target
+Ledger, Metrics, Attestation — observe/record/validate/calculate/publish/
+attest only, never discretionary over conversion).
+
+This workplan bootstraps the implementation; it does not attempt full
+production hardening, federation (PRD Roadmap Phase 6), or governance
+process design (PRD Roadmap Phase 7).
+
+## Record stack and storage ADR
+
+```task
+id: TREV-WP-0002-T01
+status: todo
+priority: high
+```
+
+`specs/TechnicalSpecificationDocument.md` is explicitly non-binding on
+language, runtime, and storage engine (§10 Traceability Note). Before writing
+code, record an ADR choosing an initial implementation stack and storage
+model (relational, document, or event-sourced/append-log-native), justified
+against the append-only, hash-chained, deterministic-fold requirements in
+TSD §3.2 and §6.1. Resolve TSD open question 5 (signature scheme and
+key-rotation record format) as part of the same ADR.
+
+## Implement Phase Manifest validation and Phase Registry
+
+```task
+id: TREV-WP-0002-T02
+status: todo
+priority: high
+```
+
+Implement the Phase Manifest schema from TSD §3.1 with a pure, deterministic
+conformance validator (required-field checks, immutability enforcement on
+`phase.initial_target.amount` and `phase.id`) per TSD §5. Implement the Phase
+Registry component (TSD §4.1) storing and serving published, immutable
+Manifests. Reject non-conformant manifests at registration, not at query
+time.
+
+## Implement the Target Ledger as an append-only, hash-chained store
+
+```task
+id: TREV-WP-0002-T03
+status: todo
+priority: high
+```
+
+Implement the Target Ledger Entry schema from TSD §3.2: the six entry types
+(`development-credit`, `remission-credit`, `credit-reversal`,
+`remission-correction`, `administrative-correction`, `conversion-checkpoint`),
+`previous_entry_hash` chaining, and signature fields. Enforce append-only
+semantics at the storage layer (no update/delete path exists, not merely
+disallowed by convention). Implement the Outstanding Target calculation as a
+pure fold over a Phase's ordered entries plus its Manifest's
+`initial_target.amount`, independently re-runnable by any conformant
+external tool (TSD §3.2 validation rules, §6.1).
+
+## Implement the Extension Registry and conformance validator
+
+```task
+id: TREV-WP-0002-T04
+status: todo
+priority: medium
+```
+
+Implement the Monetization Extension Contract schema from TSD §3.3 and its
+conformance check: required-field validation plus the rule that
+`allocation.rule` may only consume transaction-level fields and must not
+reference or redefine core terms (Phase, Initial Target, Development Credit,
+Remission Credit, Outstanding Target, Conversion Event, Future License).
+Support the `registered` / `canonical` / `deprecated` status field, with
+`canonical` promotion left as a manual, documented action (governance process
+itself is out of scope here — PRD Roadmap Phase 7).
+
+## Implement Conversion detection and Attestation publication
+
+```task
+id: TREV-WP-0002-T05
+status: todo
+priority: high
+```
+
+Implement Conversion Event detection as a pure read over the Target Ledger
+fold (Outstanding Target reaches zero) and Conversion Attestation generation
+per TSD §3.5. Enforce the legal-technical rule that attestation publication
+is evidence of conversion, never a precondition for it — any conformant
+external tool must be able to independently recompute conversion status from
+the raw Manifest and Ledger without waiting for or requiring an attestation
+(TSD §3.5, PRD FR-7/G6).
+
+## Stand up conformance test suite and a worked end-to-end example
+
+```task
+id: TREV-WP-0002-T06
+status: todo
+priority: medium
+```
+
+Build an automated conformance suite exercising: manifest validation (valid
+and deliberately invalid manifests), ledger append-only enforcement and hash
+chain integrity, extension conformance (a conforming and a non-conforming
+extension example), and a full worked Phase lifecycle from the illustrative
+example in `spec/TargetRevenueLicenseConcept.md` §23 (Initial Target
+$100,000, mixed Development/Remission Credit entries, reaching Outstanding
+Target zero, and a generated Conversion Attestation matching that example's
+numbers).