coulomb/target-revenue
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Merge spec/ into specs/: one specs directory for the whole repo

Browse source 
Moves TargetRevenueLicenseConcept.md from the separate singular spec/
directory into specs/ (git mv, preserving history) and updates every live
cross-reference (README, CONTRIBUTING, all specs/*.md, workplans, schema
comments, source docstrings, test file) to the new path.

This resolves the spec/ vs specs/ split that history/260728-SWOT-Assessment.md
flagged as a "perpetual footgun" and recommended deciding on. The historical
record of that split and the recommendation itself are left unedited in
history/ (a dated assessment, not a living document) — only README and TSD
now document the merge as resolved, with a pointer back to that history file
for context.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-07-29 10:22:14 +02:00
parent 458d3a3b60
commit 55a1756f7c
20 changed files with 67 additions and 63 deletions
Download patch file Download diff file Expand all files Collapse all files

41
specs/TechnicalSpecificationDocument.md
View file

@ -20,7 +20,7 @@ It:
* makes explicit what is **normative now**, what is **deferred to later specification work**, and what is **intentionally left open**;
* avoids encoding legal text, pricing decisions, or a fixed technology stack — those belong to the Legal Layer, canonical profiles, and future ADRs respectively.
Where a term, formula, or rule is already normatively defined in `spec/TargetRevenueLicenseConcept.md`, this document references it rather than restating it with variation. Where the PRD leaves a question open (PRD §14), this TSD does not resolve it by implication unless `specs/OpenQuestions-WorkingDefaults.md` states a **Stage 0 working default** for schema unblocking (those defaults remain provisional until human promotion into core specs).
Where a term, formula, or rule is already normatively defined in `specs/TargetRevenueLicenseConcept.md`, this document references it rather than restating it with variation. Where the PRD leaves a question open (PRD §14), this TSD does not resolve it by implication unless `specs/OpenQuestions-WorkingDefaults.md` states a **Stage 0 working default** for schema unblocking (those defaults remain provisional until human promotion into core specs).
**Normative documents (WP-0003 extract, done 2026-07-29):** day-to-day terminology, formulas, lifecycle, and rules now live in `specs/TargetRevenueFrameworkCore.md`, `specs/PhaseManifestSpecification.md`, `specs/TargetLedgerSpecification.md`, and `specs/MonetizationExtensionSpecification.md`. These extracts are stabilized references; the concept document remains the ultimate source and governs if the two ever appear to diverge.
@ -36,7 +36,7 @@ The Target Revenue Framework, as it exists in this repository, is **currently a
* `INTENT.md` — durable purpose and strategic boundaries.
* `SCOPE.md` — living Stage 0 in/out scope and sequencing rules.
* `spec/TargetRevenueLicenseConcept.md` — normative concept: terminology, formulas, rules, lifecycle.
* `specs/TargetRevenueLicenseConcept.md` — normative concept: terminology, formulas, rules, lifecycle.
* `specs/ProductRequirementsDocument.md` — product goals, scope, functional/non-functional requirements.
* `specs/TechnicalSpecificationDocument.md` (this document) — schema and component-boundary orientation.
* `specs/OpenQuestions-WorkingDefaults.md` — provisional Stage 0 defaults for open questions.
@ -51,7 +51,7 @@ JSON Schema validators, a pure Outstanding Target fold, offline conformance chec
### 1.3 Later target — reference Trust Service (PRD Phase 4b)
A centralized reference implementation providing the Phase Registry, Extension Registry, Target Ledger, Metrics, and Conversion Attestation responsibilities defined in `spec/TargetRevenueLicenseConcept.md` §14. This TSD specifies the **data model and component boundaries** that implementation must satisfy; it does not select a language, storage engine, or hosting model. Hosted implementation is **out of scope for WP-0002**.
A centralized reference implementation providing the Phase Registry, Extension Registry, Target Ledger, Metrics, and Conversion Attestation responsibilities defined in `specs/TargetRevenueLicenseConcept.md` §14. This TSD specifies the **data model and component boundaries** that implementation must satisfy; it does not select a language, storage engine, or hosting model. Hosted implementation is **out of scope for WP-0002**.
---
@ -81,7 +81,7 @@ The following constraints are **non-negotiable** and shape all downstream schema
## 3. Data Model Specifications
The following schemas formalize the YAML sketches already present in `spec/TargetRevenueLicenseConcept.md` (§16, §17, §12, §18) into typed field tables. Field names and semantics are authoritative from that document; this section adds required/recommended/optional tiering and type constraints per PRD FR-1.
The following schemas formalize the YAML sketches already present in `specs/TargetRevenueLicenseConcept.md` (§16, §17, §12, §18) into typed field tables. Field names and semantics are authoritative from that document; this section adds required/recommended/optional tiering and type constraints per PRD FR-1.
### 3.1 Phase Manifest
@ -197,7 +197,7 @@ Federation Layer → Export/verification tooling, replication protocol, s
### 4.1 Trust Service internal responsibility boundary
Per `spec/TargetRevenueLicenseConcept.md` §14.2, every Trust Service component is limited to: **observe, record, validate conformance, calculate, publish, attest.** None may **decide** whether a conversion occurs — that is a pure function of Manifest + Ledger, computable by any conformant external tool.
Per `specs/TargetRevenueLicenseConcept.md` §14.2, every Trust Service component is limited to: **observe, record, validate conformance, calculate, publish, attest.** None may **decide** whether a conversion occurs — that is a pure function of Manifest + Ledger, computable by any conformant external tool.
| Component | Responsibility | Forbidden |
|---|---|---|
@ -249,19 +249,22 @@ target-revenue/
├── LICENSE
├── history/
│ ├── 260728-InitialExploration.md
│ └── 260728-SWOT-Assessment.md
├── spec/
│ └── TargetRevenueLicenseConcept.md # normative concept (singular path, stable)
│ ├── 260728-SWOT-Assessment.md
│ └── 260728-SWOT-Followup-Spec-Workplan-Adaptations.md
├── docs/adr/
│ └── ADR-0001-stage0-library-stack.md # accepted
├── specs/
│ ├── TargetRevenueLicenseConcept.md # normative concept (ultimate source)
│ ├── ProductRequirementsDocument.md
│ ├── TechnicalSpecificationDocument.md # this document
│ ├── OpenQuestions-WorkingDefaults.md
│ └── (near-term extracts / drafts:)
│ ├── TargetRevenueFrameworkCore.md # WP-0003
│ ├── PhaseManifestSpecification.md # WP-0003
│ ├── TargetLedgerSpecification.md # WP-0003
│ ├── MonetizationExtensionSpecification.md
│ ├── TargetRevenueSourceLicense-Draft.md # WP-0001
│ ├── TargetRevenueFrameworkCore.md # WP-0003
│ ├── PhaseManifestSpecification.md # WP-0003
│ ├── TargetLedgerSpecification.md # WP-0003
│ ├── MonetizationExtensionSpecification.md # WP-0003
│ ├── TargetRevenueSourceLicense-Draft.md # WP-0001, ready for human review
│ ├── research/ # WP-0001 prior-art / legal research
│ └── (not yet started:)
│ ├── CanonicalMonetizationProfiles.md
│ ├── TargetDegenerationPolicyResearch.md
│ ├── TrustServiceProductRequirementsDocument.md # before hosted service
@ -271,11 +274,13 @@ target-revenue/
│ ├── TREV-WP-0001-license-prior-art-research.md
│ ├── TREV-WP-0002-trust-service-foundation.md
│ └── TREV-WP-0003-normative-core-extraction.md
├── schemas/ # planned — WP-0002
└── examples/ # planned — WP-0002 golden Phase package
├── schemas/ # delivered — WP-0002
├── src/target_revenue/ # delivered — WP-0002
├── examples/phase-001/ # delivered — WP-0002 golden Phase package
└── tests/ # delivered — WP-0002, 36 passing
```
**`spec/` vs `specs/` policy:** The concept document remains under singular `spec/` so git history and existing citations stay valid. New product, technical, research, and extracted normative artifacts go under plural `specs/`. Do not relocate the concept file without an explicit migration note in README and this section.
**`spec/` vs `specs/` (resolved 2026-07-29):** the concept document previously lived under a separate singular `spec/` directory; it has been merged into `specs/` so the whole repository has one specs directory. See README § `spec/` vs `specs/` for the migration note; the historical split remains visible, unedited, in `history/260728-SWOT-Assessment.md`.
---
@ -318,7 +323,7 @@ This TSD is intentionally **non-binding** with respect to:
* specific cryptographic signature algorithms;
* UI or API surface design for registry/ledger access.
Its sole purpose is to ensure that any future implementation, extension author, or federated operator can validate their work against the same schemas and boundary rules, keeping technical choices aligned with the product intent defined in `specs/ProductRequirementsDocument.md` and the normative concept in `spec/TargetRevenueLicenseConcept.md`.
Its sole purpose is to ensure that any future implementation, extension author, or federated operator can validate their work against the same schemas and boundary rules, keeping technical choices aligned with the product intent defined in `specs/ProductRequirementsDocument.md` and the normative concept in `specs/TargetRevenueLicenseConcept.md`.
---