diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index edb8bd1..9d90321 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -17,7 +17,7 @@ This repository defines a **framework concept and specifications**. It does not
 
 ## Terminology
 
-Use the normative terms from `spec/TargetRevenueLicenseConcept.md` §7 (day-to-day reference: `specs/TargetRevenueFrameworkCore.md` §1). Do **not** reintroduce ambiguous synonyms for conversion metrics (e.g. treating total project “revenue captured” as equivalent to Development Credit).
+Use the normative terms from `specs/TargetRevenueLicenseConcept.md` §7 (day-to-day reference: `specs/TargetRevenueFrameworkCore.md` §1). Do **not** reintroduce ambiguous synonyms for conversion metrics (e.g. treating total project “revenue captured” as equivalent to Development Credit).
 
 Pre-conversion software is **source-available**, not OSI Open Source.
 
diff --git a/README.md b/README.md
index 98b3498..ab13d3e 100644
--- a/README.md
+++ b/README.md
@@ -20,7 +20,7 @@ Before conversion, software under TRSL is **source-available** with commercial-u
 
 1. [`INTENT.md`](INTENT.md) — durable purpose and design principles  
 2. [`SCOPE.md`](SCOPE.md) — what is in scope *now* vs later maturity  
-3. [`spec/TargetRevenueLicenseConcept.md`](spec/TargetRevenueLicenseConcept.md) — normative concept draft (ultimate source; governs if it and the extracts below ever diverge)  
+3. [`specs/TargetRevenueLicenseConcept.md`](specs/TargetRevenueLicenseConcept.md) — normative concept draft (ultimate source; governs if it and the extracts below ever diverge)  
 4. [`specs/ProductRequirementsDocument.md`](specs/ProductRequirementsDocument.md) — goals, FRs, roadmap  
 5. [`specs/TechnicalSpecificationDocument.md`](specs/TechnicalSpecificationDocument.md) — schema field tables and boundaries  
 6. [`specs/OpenQuestions-WorkingDefaults.md`](specs/OpenQuestions-WorkingDefaults.md) — provisional Stage 0 defaults  
@@ -47,8 +47,7 @@ Extracted and stabilized from the concept draft under `workplans/TREV-WP-0003-no
 | --- | --- |
 | `INTENT.md` | Stable purpose (change rarely) |
 | `SCOPE.md` | Living Stage 0 scope |
-| `spec/` | Normative **concept** source (`TargetRevenueLicenseConcept.md`) |
-| `specs/` | Product/tech specs, working defaults, and normative extracts (WP-0003) |
+| `specs/` | Concept source, product/tech specs, working defaults, and normative extracts |
 | `workplans/` | Active delivery plans |
 | `history/` | Dated non-normative exploration and assessments |
 | `examples/` | Golden Phase packages (`phase-001`, from WP-0002) |
@@ -57,7 +56,7 @@ Extracted and stabilized from the concept draft under `workplans/TREV-WP-0003-no
 | `docs/adr/` | Architecture decisions; ADR-0001 (Stage 0 library stack) **accepted** 2026-07-29 |
 | `specs/research/` | TRSL prior-art and legal-adjacent research (WP-0001) briefing `specs/TargetRevenueSourceLicense-Draft.md` |
 
-**`spec/` vs `specs/`:** The concept document predates the plural `specs/` directory and remains under `spec/` so history and cross-references stay stable. New product/tech artifacts go under `specs/`. Do not move the concept file without a deliberate migration note.
+**`spec/` vs `specs/` (resolved 2026-07-29):** the concept document originally lived under a separate singular `spec/` directory, which `history/260728-SWOT-Assessment.md` flagged as a "perpetual footgun." It has been merged into `specs/` alongside the product/tech specs and normative extracts — there is now one specs directory for the whole repository. The historical split, and the decision to merge it, remain visible in `history/260728-SWOT-Assessment.md` (unedited, as a dated record) rather than rewritten here.
 
 ## Active work
 
diff --git a/schemas/phase_manifest.schema.json b/schemas/phase_manifest.schema.json
index 2023f0f..480dec1 100644
--- a/schemas/phase_manifest.schema.json
+++ b/schemas/phase_manifest.schema.json
@@ -2,7 +2,7 @@
   "$schema": "https://json-schema.org/draft/2020-12/schema",
   "$id": "https://target-revenue.example/schemas/phase_manifest.schema.json",
   "title": "Phase Manifest",
-  "description": "Stage 0 schema per specs/TechnicalSpecificationDocument.md §3.1 and specs/OpenQuestions-WorkingDefaults.md Q3/Q6/Q8. Field names and semantics are authoritative from spec/TargetRevenueLicenseConcept.md §16.",
+  "description": "Stage 0 schema per specs/TechnicalSpecificationDocument.md §3.1 and specs/OpenQuestions-WorkingDefaults.md Q3/Q6/Q8. Field names and semantics are authoritative from specs/TargetRevenueLicenseConcept.md §16.",
   "type": "object",
   "required": ["framework", "license", "phase"],
   "additionalProperties": false,
diff --git a/scripts/generate_golden_phase.py b/scripts/generate_golden_phase.py
index 110df51..9c2353e 100644
--- a/scripts/generate_golden_phase.py
+++ b/scripts/generate_golden_phase.py
@@ -3,7 +3,7 @@
 
 The golden Phase package must exercise a real SHA-256 hash chain, not
 hand-typed digests. This script builds the entry sequence from
-spec/TargetRevenueLicenseConcept.md §23's illustrative example and writes it
+specs/TargetRevenueLicenseConcept.md §23's illustrative example and writes it
 out via the same hashing.entry_hash() the library and tests use, so the
 fixture and the code that verifies it can never silently drift apart.
 
diff --git a/specs/MonetizationExtensionSpecification.md b/specs/MonetizationExtensionSpecification.md
index b68b8a9..eba451b 100644
--- a/specs/MonetizationExtensionSpecification.md
+++ b/specs/MonetizationExtensionSpecification.md
@@ -2,7 +2,7 @@
 
 **Document version:** TRF-Extension-0.1
 **Status:** Normative extract, Stage 0
-**Extracted from:** `spec/TargetRevenueLicenseConcept.md` §11–§12 and `specs/TechnicalSpecificationDocument.md` §3.3
+**Extracted from:** `specs/TargetRevenueLicenseConcept.md` §11–§12 and `specs/TechnicalSpecificationDocument.md` §3.3
 **Machine-readable counterpart:** `schemas/extension_contract.schema.json` — implemented and tested under `workplans/TREV-WP-0002-trust-service-foundation.md` T04 (`src/target_revenue/validation.py::validate_extension_contract`).
 
 This is a complete short specification, not a stub — it freezes the extension contract and the registered/canonical distinction. It intentionally does **not** catalog all canonical profiles in depth; that remains a follow-on, `specs/CanonicalMonetizationProfiles.md` (planned).
diff --git a/specs/PhaseManifestSpecification.md b/specs/PhaseManifestSpecification.md
index 7f29ae1..6afb472 100644
--- a/specs/PhaseManifestSpecification.md
+++ b/specs/PhaseManifestSpecification.md
@@ -2,7 +2,7 @@
 
 **Document version:** TRF-PhaseManifest-0.1
 **Status:** Normative extract, Stage 0
-**Extracted from:** `spec/TargetRevenueLicenseConcept.md` §16 and `specs/TechnicalSpecificationDocument.md` §3.1
+**Extracted from:** `specs/TargetRevenueLicenseConcept.md` §16 and `specs/TechnicalSpecificationDocument.md` §3.1
 **Machine-readable counterpart:** `schemas/phase_manifest.schema.json` — implemented and tested under `workplans/TREV-WP-0002-trust-service-foundation.md` T02 (`src/target_revenue/validation.py::validate_phase_manifest`). This document is the prose normative reference; the schema file is the authoritative machine-checkable definition. They must not drift — a change to one requires reviewing the other.
 
 ---
diff --git a/specs/ProductRequirementsDocument.md b/specs/ProductRequirementsDocument.md
index cbefb4c..367483a 100644
--- a/specs/ProductRequirementsDocument.md
+++ b/specs/ProductRequirementsDocument.md
@@ -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) |
 | --- | --- | --- |
diff --git a/specs/TargetLedgerSpecification.md b/specs/TargetLedgerSpecification.md
index 6deaedb..59d7c08 100644
--- a/specs/TargetLedgerSpecification.md
+++ b/specs/TargetLedgerSpecification.md
@@ -2,7 +2,7 @@
 
 **Document version:** TRF-Ledger-0.1
 **Status:** Normative extract, Stage 0
-**Extracted from:** `spec/TargetRevenueLicenseConcept.md` §17 and `specs/TechnicalSpecificationDocument.md` §3.2
+**Extracted from:** `specs/TargetRevenueLicenseConcept.md` §17 and `specs/TechnicalSpecificationDocument.md` §3.2
 **Machine-readable counterpart:** `schemas/ledger_entry.schema.json` — implemented and tested under `workplans/TREV-WP-0002-trust-service-foundation.md` T03 (`src/target_revenue/hashing.py`, `src/target_revenue/fold.py`). This document is the prose normative reference; the schema and library are the authoritative machine-checkable implementation.
 
 ---
diff --git a/specs/TargetRevenueFrameworkCore.md b/specs/TargetRevenueFrameworkCore.md
index ae893e1..e20afce 100644
--- a/specs/TargetRevenueFrameworkCore.md
+++ b/specs/TargetRevenueFrameworkCore.md
@@ -2,7 +2,7 @@
 
 **Document version:** TRF-Core-0.1
 **Status:** Normative extract, Stage 0
-**Extracted from:** `spec/TargetRevenueLicenseConcept.md` §7–§10, §18, §22 (concept draft remains the source; this document freezes day-to-day terminology per `workplans/TREV-WP-0003-normative-core-extraction.md`)
+**Extracted from:** `specs/TargetRevenueLicenseConcept.md` §7–§10, §18, §22 (concept draft remains the source; this document freezes day-to-day terminology per `workplans/TREV-WP-0003-normative-core-extraction.md`)
 **Authority:** This is the day-to-day normative reference for terminology, formulas, lifecycle, and rules. It does not invent meaning beyond the concept document — where the two ever appear to diverge, the concept document governs and this extract must be corrected, not reinterpreted.
 **Working defaults:** Several fields below are marked **Stage 0 working default** — provisional per `specs/OpenQuestions-WorkingDefaults.md`, not yet promoted to permanent norm. Everything else in this document reflects concept §24 open questions that remain genuinely open; this extract does not resolve them by omission.
 
diff --git a/spec/TargetRevenueLicenseConcept.md b/specs/TargetRevenueLicenseConcept.md
similarity index 99%
rename from spec/TargetRevenueLicenseConcept.md
rename to specs/TargetRevenueLicenseConcept.md
index 924a368..19a906b 100644
--- a/spec/TargetRevenueLicenseConcept.md
+++ b/specs/TargetRevenueLicenseConcept.md
@@ -5,7 +5,7 @@
 **Document status:** Concept draft  
 **Purpose:** Define the conceptual foundation for a revenue-triggered software licensing and monetization framework.  
 
-**Related documents:** Living scope in `SCOPE.md`; product requirements in `specs/ProductRequirementsDocument.md`; schema orientation in `specs/TechnicalSpecificationDocument.md`; provisional open-question defaults in `specs/OpenQuestions-WorkingDefaults.md`. Normative extracts under `specs/` (WP-0003) will freeze day-to-day terminology without relocating this file (`spec/` vs `specs/` policy: README / TSD §7).
+**Related documents:** Living scope in `SCOPE.md`; product requirements in `specs/ProductRequirementsDocument.md`; schema orientation in `specs/TechnicalSpecificationDocument.md`; provisional open-question defaults in `specs/OpenQuestions-WorkingDefaults.md`. Normative extracts under `specs/` (WP-0003) freeze day-to-day terminology; this file remains the ultimate source and governs if the two ever appear to diverge. This file moved from a separate `spec/` directory into `specs/` on 2026-07-29 (README § `spec/` vs `specs/`); its content and git history are otherwise unchanged.
 
 > The Target Revenue Framework combines a source license and trust service to monetize software development transparently until a defined target is satisfied and the governed release automatically becomes permissively open source.
 
diff --git a/specs/TargetRevenueSourceLicense-Draft.md b/specs/TargetRevenueSourceLicense-Draft.md
index 78e3fa2..f6b8ec1 100644
--- a/specs/TargetRevenueSourceLicense-Draft.md
+++ b/specs/TargetRevenueSourceLicense-Draft.md
@@ -16,7 +16,7 @@ Every clause below is one of:
 - **[WORKING DEFAULT]** — reflects a Stage 0 provisional answer from `specs/OpenQuestions-WorkingDefaults.md`; not yet promoted to permanent norm.
 - **[OPEN]** — genuinely undecided; concept §24 or PRD §14 question not yet resolved by any research task.
 
-This skeleton follows the component list already identified in `spec/TargetRevenueLicenseConcept.md` §21.1, and incorporates the research findings in `specs/research/`.
+This skeleton follows the component list already identified in `specs/TargetRevenueLicenseConcept.md` §21.1, and incorporates the research findings in `specs/research/`.
 
 ---
 
@@ -39,7 +39,7 @@ Per `specs/research/TRSL-Jurisdiction-StandardTerms.md` §5, German AGB law's Tr
 
 **[CONFIRMED BY RESEARCH]** Restricting commercial use for a protected period, while permitting broader noncommercial use, is a well-established license category (Fair Source's "minimal restrictions to protect the producer's business model," `specs/research/TRSL-Terminology-Guardrails.md` §2) with direct precedent in BSL 1.1's production-use gate and FSL's narrower "do not undermine the producer" restriction (`specs/research/TRSL-PriorArt-Survey.md` §2).
 
-**[LEGAL]** The commercial-use gate itself (requiring a Commercial Use Agreement per `spec/TargetRevenueLicenseConcept.md` §21.2) needs drafted text; the **definition** of "commercial use" that triggers it is the single highest Transparenzgebot-exposure term in the framework (`specs/research/TRSL-Jurisdiction-StandardTerms.md` §4 item 2) and is explicitly **[OPEN]** pending legal input.
+**[LEGAL]** The commercial-use gate itself (requiring a Commercial Use Agreement per `specs/TargetRevenueLicenseConcept.md` §21.2) needs drafted text; the **definition** of "commercial use" that triggers it is the single highest Transparenzgebot-exposure term in the framework (`specs/research/TRSL-Jurisdiction-StandardTerms.md` §4 item 2) and is explicitly **[OPEN]** pending legal input.
 
 ## 4. Modification and redistribution during the protected Phase [LEGAL]
 
@@ -55,7 +55,7 @@ Not resolved by this research pass. Recommend drafting from the BSL 1.1 baseline
 
 **[WORKING DEFAULT, Q3]** `future_license` ∈ {MIT, Apache-2.0}, chosen per Phase at declaration time. See `specs/research/TRSL-FutureLicense-PatentPrecedent.md` §3 for a project-level recommendation (Apache-2.0 default where patentable technique is plausible; MIT where simplicity is prioritized and patent risk is judged negligible) — this is Phase-author guidance, not a framework-level forced default.
 
-**[CONFIRMED BY RESEARCH]** The conversion mechanism should follow the established two-step structure confirmed across both BSL 1.1 and FSL (`specs/research/TRSL-PriorArt-Survey.md` §2, §4): the restricted rights **terminate**, and rights under the Future License are granted **in their place**, automatically, at the Conversion Event — not a discretionary re-licensing act. This matches `spec/TargetRevenueLicenseConcept.md` Rule 6 and Rule 9 exactly and requires no structural invention; only legal wording.
+**[CONFIRMED BY RESEARCH]** The conversion mechanism should follow the established two-step structure confirmed across both BSL 1.1 and FSL (`specs/research/TRSL-PriorArt-Survey.md` §2, §4): the restricted rights **terminate**, and rights under the Future License are granted **in their place**, automatically, at the Conversion Event — not a discretionary re-licensing act. This matches `specs/TargetRevenueLicenseConcept.md` Rule 6 and Rule 9 exactly and requires no structural invention; only legal wording.
 
 **[LEGAL]** Final clause text. Recommend phrasing anchored on: "The Conversion Event occurs automatically when [Outstanding Target, as defined in §1, equals zero]. Upon the Conversion Event, the rights granted under §3 of this License terminate, and the Future License identified in the applicable Phase Manifest is granted in their place, without further act by either party." Precise legal phrasing per counsel.
 
@@ -79,11 +79,11 @@ Per `specs/research/TRSL-Terminology-Guardrails.md` §3: pre-conversion software
 
 ## 11. What this draft does not attempt
 
-Per `spec/TargetRevenueLicenseConcept.md` §21.3 and `SCOPE.md` §3: this draft does not attempt Commercial Use Agreement terms, Operations/Service Agreement terms, or any monetization-extension-specific pricing language — those are governed separately (`specs/MonetizationExtensionSpecification.md`).
+Per `specs/TargetRevenueLicenseConcept.md` §21.3 and `SCOPE.md` §3: this draft does not attempt Commercial Use Agreement terms, Operations/Service Agreement terms, or any monetization-extension-specific pricing language — those are governed separately (`specs/MonetizationExtensionSpecification.md`).
 
 ## 12. Legal review requirement
 
-This document is a product/engineering research synthesis, not legal advice or final license text. Per `spec/TargetRevenueLicenseConcept.md` §21.5, final drafting requires specialist review covering (at minimum): automatic conditional license grants, standard-terms law (Transparenzgebot and equivalents — `specs/research/TRSL-Jurisdiction-StandardTerms.md`), copyright and patent rights, contributor rights (`specs/research/TRSL-ContributorRights-Research.md`), audit and evidence provisions, international enforceability, consumer/business distinctions (`specs/research/TRSL-Jurisdiction-StandardTerms.md` §2's EU consumer-law scoping), and insolvency/service-discontinuity scenarios.
+This document is a product/engineering research synthesis, not legal advice or final license text. Per `specs/TargetRevenueLicenseConcept.md` §21.5, final drafting requires specialist review covering (at minimum): automatic conditional license grants, standard-terms law (Transparenzgebot and equivalents — `specs/research/TRSL-Jurisdiction-StandardTerms.md`), copyright and patent rights, contributor rights (`specs/research/TRSL-ContributorRights-Research.md`), audit and evidence provisions, international enforceability, consumer/business distinctions (`specs/research/TRSL-Jurisdiction-StandardTerms.md` §2's EU consumer-law scoping), and insolvency/service-discontinuity scenarios.
 
 ---
 
diff --git a/specs/TechnicalSpecificationDocument.md b/specs/TechnicalSpecificationDocument.md
index 6e1df8b..6171991 100644
--- a/specs/TechnicalSpecificationDocument.md
+++ b/specs/TechnicalSpecificationDocument.md
@@ -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`.
 
 ---
 
diff --git a/specs/research/TRSL-ContributorRights-Research.md b/specs/research/TRSL-ContributorRights-Research.md
index b464249..cdc73a7 100644
--- a/specs/research/TRSL-ContributorRights-Research.md
+++ b/specs/research/TRSL-ContributorRights-Research.md
@@ -12,7 +12,7 @@ A typical open-source project only needs contributors to grant rights sufficient
 1. the restricted TRSL Phase license (commercial-use-gated, source-available), and
 2. the eventual, automatic, irrevocable Future License (MIT or Apache-2.0) at conversion — which the licensor must be able to promise **today**, before conversion has happened, on behalf of every contribution folded into that Milestone Release.
 
-This is the specific gap `spec/TargetRevenueLicenseConcept.md` §21.4 already identifies ("The project must hold sufficient rights to promise both... Contributor arrangements may therefore require copyright assignment or an appropriately broad contributor license agreement").
+This is the specific gap `specs/TargetRevenueLicenseConcept.md` §21.4 already identifies ("The project must hold sufficient rights to promise both... Contributor arrangements may therefore require copyright assignment or an appropriately broad contributor license agreement").
 
 ## 2. What the Developer Certificate of Origin actually certifies
 
@@ -43,7 +43,7 @@ BSL and FSL projects (MariaDB and successors) are typically **single-copyright-h
 
 - **`CONTRIBUTING.md`**: once a CLA is drafted and adopted, update the "External contributions and governed code" section to reference it and lift the current blanket block for repositories that adopt it.
 - **T06 draft skeleton**: include a clause (or a pointer to a companion CLA document) stating that TRSL's automatic Future License conversion applies to the Milestone Release as a whole, and that contributor rights sufficient for that conversion are a precondition for a contribution's inclusion — mark the CLA's own text as a separate deliverable, `[LEGAL]`, not something to draft inline in the source license.
-- **`spec/TargetRevenueLicenseConcept.md` §21.4**: no change needed — this research confirms and specifies its existing recommendation rather than contradicting it.
+- **`specs/TargetRevenueLicenseConcept.md` §21.4**: no change needed — this research confirms and specifies its existing recommendation rather than contradicting it.
 
 ## 6. Open item
 
diff --git a/specs/research/TRSL-FutureLicense-PatentPrecedent.md b/specs/research/TRSL-FutureLicense-PatentPrecedent.md
index 647c342..ba8b53c 100644
--- a/specs/research/TRSL-FutureLicense-PatentPrecedent.md
+++ b/specs/research/TRSL-FutureLicense-PatentPrecedent.md
@@ -47,7 +47,7 @@ This is a real, meaningful difference: Apache-2.0 gives downstream users an expl
 - But TRSL's commercial entitlement model (paying for commercial-use rights) creates a closer analogy to a *commercial software license* than a permissive OSS license, and commercial software licenses conventionally do address patent scope explicitly to avoid ambiguity about what a paying commercial licensee actually receives.
 - A minimal express patent license for the pre-conversion Phase — scoped like Apache-2.0's Section 3 (contribution-scoped, litigation-terminable) — would give commercial entitlement holders the same patent peace of mind Apache-2.0 gives Future License adopters, without over-promising.
 
-This item should be marked `[LEGAL]` in the T06 draft skeleton: the *recommendation to include something* is a research conclusion; the *exact clause text* requires specialist review (`spec/TargetRevenueLicenseConcept.md` §21.5).
+This item should be marked `[LEGAL]` in the T06 draft skeleton: the *recommendation to include something* is a research conclusion; the *exact clause text* requires specialist review (`specs/TargetRevenueLicenseConcept.md` §21.5).
 
 ## 5. For working defaults
 
diff --git a/specs/research/TRSL-PriorArt-Survey.md b/specs/research/TRSL-PriorArt-Survey.md
index 0890fb1..a5c9770 100644
--- a/specs/research/TRSL-PriorArt-Survey.md
+++ b/specs/research/TRSL-PriorArt-Survey.md
@@ -1,7 +1,7 @@
 # TRSL Prior-Art Survey: Delayed-Open-Source and Source-Available Models
 
 **Document status:** Research artifact, Stage 0 (`workplans/TREV-WP-0001-license-prior-art-research.md` T01)
-**Not legal advice.** Findings below are drawn from primary-source license texts (fetched 2026-07-29) and are offered as engineering/product research to brief specialist legal drafting (`SCOPE.md` §4, `spec/TargetRevenueLicenseConcept.md` §21.5). Verify current license text before drafting, as license texts are occasionally revised by their stewards.
+**Not legal advice.** Findings below are drawn from primary-source license texts (fetched 2026-07-29) and are offered as engineering/product research to brief specialist legal drafting (`SCOPE.md` §4, `specs/TargetRevenueLicenseConcept.md` §21.5). Verify current license text before drafting, as license texts are occasionally revised by their stewards.
 
 ---
 
diff --git a/specs/research/TRSL-Terminology-Guardrails.md b/specs/research/TRSL-Terminology-Guardrails.md
index d3f31c3..413c9df 100644
--- a/specs/research/TRSL-Terminology-Guardrails.md
+++ b/specs/research/TRSL-Terminology-Guardrails.md
@@ -13,7 +13,7 @@ The Open Source Definition (OSD), maintained by the Open Source Initiative, stat
 >
 > **Clause 6 — No Discrimination Against Fields of Endeavor:** "The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research."
 
-TRSL's pre-conversion state requires a commercial entitlement for commercial use (`spec/TargetRevenueLicenseConcept.md` §21.1). That is precisely a field-of-endeavor restriction — "may not be used commercially without payment" restricts a specific field of endeavor (business use) exactly as Clause 6's own example describes. **There is no ambiguity here**: pre-conversion TRSL cannot be described as Open Source under the OSD, full stop, regardless of how the restriction is priced, credited, or eventually lifted.
+TRSL's pre-conversion state requires a commercial entitlement for commercial use (`specs/TargetRevenueLicenseConcept.md` §21.1). That is precisely a field-of-endeavor restriction — "may not be used commercially without payment" restricts a specific field of endeavor (business use) exactly as Clause 6's own example describes. **There is no ambiguity here**: pre-conversion TRSL cannot be described as Open Source under the OSD, full stop, regardless of how the restriction is priced, credited, or eventually lifted.
 
 This is not a defect to work around — it is a category TRSL should state plainly and repeatedly, because the alternative (softening the language to sound more "open" than it is) is exactly the kind of ambiguity that creates legal and reputational risk later.
 
diff --git a/src/target_revenue/fold.py b/src/target_revenue/fold.py
index f729361..007676c 100644
--- a/src/target_revenue/fold.py
+++ b/src/target_revenue/fold.py
@@ -1,7 +1,7 @@
 """Pure Outstanding Target fold over a Phase's Target Ledger.
 
 Outstanding Target = max(0, Initial Target - Development Credit - Remission
-Credit), per spec/TargetRevenueLicenseConcept.md §7.7/§13 and
+Credit), per specs/TargetRevenueLicenseConcept.md §7.7/§13 and
 specs/TechnicalSpecificationDocument.md §3.2. This module contains no I/O:
 given the same (initial_target_amount, entries) it always returns the same
 result (TSD §6.1 determinism), so any independent implementation can
diff --git a/tests/test_ledger_fold.py b/tests/test_ledger_fold.py
index 089f2d2..76472de 100644
--- a/tests/test_ledger_fold.py
+++ b/tests/test_ledger_fold.py
@@ -44,7 +44,7 @@ def test_reordered_entries_break_hash_chain():
 
 
 def test_fold_matches_concept_section_23_first_checkpoint():
-    """spec/TargetRevenueLicenseConcept.md §23: after the first four entries,
+    """specs/TargetRevenueLicenseConcept.md §23: after the first four entries,
     Development Credit $37,000, Remission Credit $18,000, Outstanding $45,000."""
     manifest = golden_manifest()
     first_four = golden_entries()[:4]
@@ -58,7 +58,7 @@ def test_fold_matches_concept_section_23_first_checkpoint():
 
 
 def test_fold_reaches_zero_and_converts():
-    """spec/TargetRevenueLicenseConcept.md §23: full six-entry sequence
+    """specs/TargetRevenueLicenseConcept.md §23: full six-entry sequence
     reaches Outstanding Target = 0 (Development Credit $67,000 + Remission
     Credit $33,000 = Initial Target $100,000)."""
     manifest = golden_manifest()
diff --git a/workplans/TREV-WP-0001-license-prior-art-research.md b/workplans/TREV-WP-0001-license-prior-art-research.md
index 9a9bf8a..970cbb1 100644
--- a/workplans/TREV-WP-0001-license-prior-art-research.md
+++ b/workplans/TREV-WP-0001-license-prior-art-research.md
@@ -16,7 +16,7 @@ state_hub_workstream_id: "6f91cef8-c75c-4955-aaba-0b240390fbe9"
 
 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
+already established in `specs/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,
@@ -64,7 +64,7 @@ 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.
+`specs/TargetRevenueLicenseConcept.md` §7, §10, §18.
 
 **Deliverable path (suggested):** `history/` or `specs/research/TRSL-PriorArt-Survey.md`.
 
@@ -120,7 +120,7 @@ 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
+`specs/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.
 
@@ -156,7 +156,7 @@ 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).
+`specs/TargetRevenueLicenseConcept.md` §21.4).
 
 Update `CONTRIBUTING.md` if the recommendation changes interim policy
 (external contributions still blocked for governed Milestone Releases until
@@ -208,11 +208,11 @@ human_accept_required: true
 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,
+`specs/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.
+`specs/TargetRevenueLicenseConcept.md` §21.5.
 
 **Human accept gate:** Do not set this task to `done` until a human maintainer
 explicitly accepts the skeleton as adequate briefing material for counsel.
diff --git a/workplans/TREV-WP-0003-normative-core-extraction.md b/workplans/TREV-WP-0003-normative-core-extraction.md
index dca1579..c40a0ff 100644
--- a/workplans/TREV-WP-0003-normative-core-extraction.md
+++ b/workplans/TREV-WP-0003-normative-core-extraction.md
@@ -18,7 +18,7 @@ Extract stable, versioned normative documents from the exploratory concept
 draft so that schemas (WP-0002), legal skeleton (WP-0001), and later Trust
 Service work share one frozen vocabulary.
 
-**Authority chain:** `spec/TargetRevenueLicenseConcept.md` remains the
+**Authority chain:** `specs/TargetRevenueLicenseConcept.md` remains the
 concept source. Extracted docs under `specs/` become the day-to-day
 normative references for implementers; they must not invent divergent
 meanings for core terms (PRD §6.1). Working defaults that affect required
@@ -106,7 +106,7 @@ Updated `schemas/ledger_entry.schema.json`, `src/target_revenue/fold.py`,
 `specs/TargetLedgerSpecification.md` §2/§6, `specs/TechnicalSpecificationDocument.md`
 §3.2, and `specs/ProductRequirementsDocument.md` FR-5. Added dedicated test
 coverage (`tests/test_ledger_fold.py`) for both new types plus a regression
-test confirming the old unsplit type name is now rejected. `spec/TargetRevenueLicenseConcept.md`
+test confirming the old unsplit type name is now rejected. `specs/TargetRevenueLicenseConcept.md`
 §17 was left unedited — its entry-type list is explicitly non-exhaustive
 ("may include"), so the split specializes rather than contradicts it.
 
@@ -204,7 +204,7 @@ accept):
       `product-ideation` and `general-consulting` as not yet fixture-backed.
 - [ ] Cross-links (T05) — confirm PRD §6.1/§6.2, TSD §0/§1.1, README, and
       CONTRIBUTING.md all point at the new extracts without contradicting
-      `spec/TargetRevenueLicenseConcept.md` as ultimate authority.
+      `specs/TargetRevenueLicenseConcept.md` as ultimate authority.
 - [ ] No open question (concept §24) is answered by omission — each extract
       either cites a working default explicitly or states the item remains
       open.