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

22
specs/ProductRequirementsDocument.md
View file

@ -3,10 +3,10 @@
Status: Draft v0.2
Date: 2026-07-28
Owner: target-revenue initiative
Primary artifacts: `INTENT.md`, `SCOPE.md`, `spec/TargetRevenueLicenseConcept.md`, `history/260728-InitialExploration.md`
Primary artifacts: `INTENT.md`, `SCOPE.md`, `specs/TargetRevenueLicenseConcept.md`, `history/260728-InitialExploration.md`
Living scope: `SCOPE.md` states Stage 0 in/out boundaries and workplan sequencing (normative extract + schemas/fold before hosted Trust Service).
Working defaults: `specs/OpenQuestions-WorkingDefaults.md` holds provisional answers to §14 items for Stage 0 unblocking; promotion into core requires human accept.
Terminology alignment: This document does not redefine terms already normatively defined in `spec/TargetRevenueLicenseConcept.md`. Where a definitive formula, rule, or schema already exists there, this PRD references it rather than restating it with variation.
Terminology alignment: This document does not redefine terms already normatively defined in `specs/TargetRevenueLicenseConcept.md`. Where a definitive formula, rule, or schema already exists there, this PRD references it rather than restating it with variation.
---
@ -26,7 +26,7 @@ The framework is intended to become a **monetization canon for exploratory softw
## 2. Problem statement
Exploratory product development creates a coordination problem (INTENT.md, `spec/TargetRevenueLicenseConcept.md` §2):
Exploratory product development creates a coordination problem (INTENT.md, `specs/TargetRevenueLicenseConcept.md` §2):
- new software capabilities require up-front work and risk-taking;
- fully proprietary licensing restricts adoption, inspection, and ecosystem participation;
@ -42,7 +42,7 @@ Without a shared framework, every project reinvents ad hoc answers to: which pay
### G1 — Minimal constitutional core
The normative kernel (Phase, Milestone Release, Initial Target, Development Credit, Remission Credit, Outstanding Target, Conversion Event, Future License) shall remain small enough to explain in one paragraph and apply consistently across projects (`spec/TargetRevenueLicenseConcept.md` §7, §22).
The normative kernel (Phase, Milestone Release, Initial Target, Development Credit, Remission Credit, Outstanding Target, Conversion Event, Future License) shall remain small enough to explain in one paragraph and apply consistently across projects (`specs/TargetRevenueLicenseConcept.md` §7, §22).
### G2 — Automatic, irrevocable conversion
@ -76,7 +76,7 @@ A later Phase may govern new development but must never withdraw or restrict rig
## 4. Non-goals
Per `INTENT.md` "Strategic Boundaries" and `spec/TargetRevenueLicenseConcept.md` §5, the framework shall not:
Per `INTENT.md` "Strategic Boundaries" and `specs/TargetRevenueLicenseConcept.md` §5, the framework shall not:
1. Govern the products or software releases of individual TRSL Phases beyond the framework's own reference material.
2. Define customer-specific commercial, hosting, support, consulting, or service agreements.
@ -111,7 +111,7 @@ Per `INTENT.md` "Strategic Boundaries" and `spec/TargetRevenueLicenseConcept.md`
### 6.1 Core entities
The seven core terms and their relationships are normatively defined in `spec/TargetRevenueLicenseConcept.md` §7 (day-to-day reference: `specs/TargetRevenueFrameworkCore.md` §1, WP-0003 extract) and must not be restated with variant meaning elsewhere in the framework:
The seven core terms and their relationships are normatively defined in `specs/TargetRevenueLicenseConcept.md` §7 (day-to-day reference: `specs/TargetRevenueFrameworkCore.md` §1, WP-0003 extract) and must not be restated with variant meaning elsewhere in the framework:
| Entity | Summary |
|---|---|
@ -129,7 +129,7 @@ The seven core terms and their relationships are normatively defined in `spec/Ta
### 6.2 Core lifecycle
Five verbs (§9): **Define → Allocate → Credit / Remit → Convert**. See the state diagram and rule set in `spec/TargetRevenueLicenseConcept.md` §9–§10 (day-to-day reference: `specs/TargetRevenueFrameworkCore.md` §3–§4) for the authoritative lifecycle and the nine core rules (immutable phase definition, explicit allocation, no duplicate credit, settled-payment recognition, separate remission, automatic conversion, permanent prior freedom, correction without erasure, conversion irreversibility).
Five verbs (§9): **Define → Allocate → Credit / Remit → Convert**. See the state diagram and rule set in `specs/TargetRevenueLicenseConcept.md` §9–§10 (day-to-day reference: `specs/TargetRevenueFrameworkCore.md` §3–§4) for the authoritative lifecycle and the nine core rules (immutable phase definition, explicit allocation, no duplicate credit, settled-payment recognition, separate remission, automatic conversion, permanent prior freedom, correction without erasure, conversion irreversibility).
### 6.3 Monetization architecture
@ -298,7 +298,7 @@ A proposed addition to the normative core must pass three tests — universal, i
## 10. Architecture proposal
The framework is organized into four layers (`spec/TargetRevenueLicenseConcept.md` §6, mermaid diagram):
The framework is organized into four layers (`specs/TargetRevenueLicenseConcept.md` §6, mermaid diagram):
```text
Target Revenue Framework
@ -329,7 +329,7 @@ The architectural invariant governing every layer: **the license establishes leg
### 11.1 MVP scope
The MVP corresponds to the "Proposed Initial Deliverables" already identified in `spec/TargetRevenueLicenseConcept.md` §25, sequenced so that **runnable offline specification** lands before a hosted Trust Service:
The MVP corresponds to the "Proposed Initial Deliverables" already identified in `specs/TargetRevenueLicenseConcept.md` §25, sequenced so that **runnable offline specification** lands before a hosted Trust Service:
**Tier A — Stage 0 package (current delivery focus; `SCOPE.md` §5):**
@ -384,7 +384,7 @@ Workplan mapping (see `workplans/`, `SCOPE.md` §4):
### Phase 0 — Concept consolidation (largely complete)
- `INTENT.md`, `SCOPE.md`, and `spec/TargetRevenueLicenseConcept.md` established.
- `INTENT.md`, `SCOPE.md`, and `specs/TargetRevenueLicenseConcept.md` established.
- This PRD and TSD translate the concept into product goals, requirements, and schema orientation.
- Stage 0 working defaults published; SWOT assessment under `history/260728-SWOT-Assessment.md`.
@ -445,7 +445,7 @@ Workplan mapping (see `workplans/`, `SCOPE.md` §4):
## 14. Open questions
Carried forward from `spec/TargetRevenueLicenseConcept.md` §24. **Provisional Stage 0 answers** live in `specs/OpenQuestions-WorkingDefaults.md` and do not close these questions permanently.
Carried forward from `specs/TargetRevenueLicenseConcept.md` §24. **Provisional Stage 0 answers** live in `specs/OpenQuestions-WorkingDefaults.md` and do not close these questions permanently.
| # | Question | Stage 0 working default (summary) |
| --- | --- | --- |