T01: specs/TargetDegenerationPolicyResearch.md. Survey finds no
precedent (BSL/FSL/Elastic) implements progress-sensitive degeneration
- TRSL's model is original design. Proposes a candidate v1 formula
(90-day rolling "quiet period" pause on Remission Credit accrual
during active Development Credit periods), resolves the
contributor-diversity input as explicitly not-adopted (no
gaming-resistant signal exists yet), and resolves the
longstop/progress-sensitivity relationship as a hard, unconditional
backstop. Does not recommend v0 vs v1 for T02 - that's the human gate.
T02: recommendation added (confirm v0 for the first pilot cohort, name
v1 as the next iteration) - left todo per the human-accept policy.
T03: specs/CanonicalMonetizationProfiles.md with worked narratives for
all six catalog profiles, plus two new fixtures (product-ideation,
general-consulting), both schema-validated and added to the
parametrized conformance test.
T04: specs/CanonicalizationReviewChecklist.md, an 8-item checklist
layered on the already-implemented promote_extension_canonical()
mechanism (WP-0006-T03) - defines what a reviewer must verify, not a
new promotion mechanism.
migrations/0004_breach_records.sql models a case's lifecycle as
append-only events (alleged/cured/determined/terminated) grouped by
case_id rather than one mutable row - resolution is always a new,
later event, never an edit. A CHECK constraint makes the
anonymized-default rule (License V1C1 §7.4) a database fact:
named_entitlement_holder can be set if and only if anonymized = false.
src/target_revenue/breach_record.py's publish_breach_event() enforces
per-Licensor phase ownership and rejects named-disclosure requests
that don't also set named_disclosure_authorized_under_cua: true - the
Trust Service records the Licensor's assertion that the CUA's naming
clause authorizes it, it never verifies the underlying CUA text
itself. Signs every event with the same instance Ed25519 key already
used for Ledger entries and Attestations.
Adds POST/GET /phases/{id}/breach-records. Guarded the .registry
import behind a lazy in-function import (matching attestation.py's
TYPE_CHECKING pattern) so tests/test_breach_record.py (7 tests) runs
under plain system Python with no psycopg dependency. 5 new
Docker-gated tests cover the default-anonymized lifecycle, the
named-disclosure authorization gate, cross-Licensor rejection,
signature verification, and DB-level UPDATE/DELETE rejection.
This closes WP-0006 again - all 9 tasks done.
Reopens WP-0006 (status: active) to track the gap T01's Trust Service
PRD flagged: the Breach/Compliance Record component (TSD §4.1, added
alongside License V1C1 §7.4) postdates WP-0002 and was never assigned
to T03-T08. Scopes it: publish alleged/determined breach status
without adjudicating, default anonymized with CUA-§9-gated named
disclosure, append-only per the existing pattern, reusing the
per-Licensor token model for writes.
tests/test_hosted_conformance.py (6 Docker-gated tests) addresses all
three requirements from the task description: the golden Phase example
(manifest + full ledger + all 4 extensions) replayed through the
hosted API reproduces exactly the offline-established outcome
(Development Credit 67000, Remission Credit 33000, Outstanding Target
0, MIT) including the hosted Attestation; two Phases under different
Licensors operate with interleaved appends and are proven isolated
both positively and negatively (cross-Licensor writes rejected); a
parametrized regression test across four ledger shapes (credits-only,
remission, reversal, admin corrections) confirms hosted-append-then-
offline-fold always matches expected totals.
WP-0006 is now finished - all 8 tasks (PRD, ADR-0002, registries,
ledger API, metrics, attestation, onboarding, conformance) done. T01's
flagged gap (no task owns hosting the Breach/Compliance Record
component from License V1C1 §7.4) remains open and unassigned.
specs/TrustServiceOnboarding.md defines the mechanism: a Phase Manifest
file is committed to the declaring repo (durable, independently
foldable forever) and separately registered with the hosted service;
once registered, the Ledger's live authoritative copy is the hosted
service only, not a second competing file. Licensor token bootstrapping
is explicitly out of scope here (a WP-0008-T01 governance action).
scripts/trf_onboard.py: a dependency-light CLI (stdlib urllib +
target_revenue.validation only, no FastAPI/psycopg needed to onboard a
Phase) with validate/register-phase/append-entry/status subcommands.
The Licensor token is read only from a named environment variable,
never accepted as a literal argument.
tests/test_trf_onboard.py (4 tests, no network/Docker) proves
invalid-manifest and missing-token-env cases fail before any HTTP
attempt, by monkeypatching the request function to raise if called.
tests/test_onboarding_hosted.py (1 Docker-gated test) runs an actual
uvicorn server on a real socket and drives the full
register -> append -> status round trip through the CLI as an external
repo would invoke it.
migrations/0003_attestations.sql: one row per Phase, no UPDATE/DELETE
grant for trf_app (a published attestation is permanent).
src/target_revenue/attestation.py: publish_attestation() is idempotent
(existing row returned unchanged, never regenerated) and derives
conversion_timestamp from the ledger itself via _find_conversion_prefix(),
which finds the earliest prefix where the fold reaches Outstanding
Target = 0 rather than trusting entries[-1] or wall-clock publish time -
so a later unrelated entry can never change an already-converged Phase's
recorded conversion moment. Raises NotConvertedError rather than
fabricating a conversion. Reuses conversion.generate_attestation()
unchanged. Guarded the psycopg import behind TYPE_CHECKING so the pure
helper stays testable under plain system Python.
service/app.py adds GET /phases/{id}/attestation (unauthenticated,
publish-on-first-observation).
tests/test_attestation.py (3 tests, no Docker/Postgres) proves the
earliest-crossing behavior. 6 new Docker-gated tests in
test_ledger_hosting.py cover pre-conversion 404, the core
legal-technical property that /metrics facts/calculations/forecasts
are identical whether or not /attestation was ever called, one-time
publication, signature verification, and DB-level UPDATE/DELETE
rejection.
src/target_revenue/metrics.py: compute_metrics(manifest, entries, as_of)
is pure/deterministic like fold.py, reusing fold.py/conversion.py
unchanged. Returns facts/calculations/forecasts as three explicitly
separated blocks (TrustServicePRD TS-FR-5), covering the mandatory Q9
set plus the recommended velocity/forecast tier - forecasts are always
null rather than populated once a Phase has converted or velocity is
non-positive, so nothing disguises a projection as a fact.
Adds GET /phases/{id}/metrics (unauthenticated per FR-9/FR-10).
tests/test_metrics.py (6 tests) needs no Docker/Postgres and runs
under plain system Python. One new Docker-gated test in
test_ledger_hosting.py proves the hosted /metrics response exactly
matches compute_metrics() run offline against the same export.
migrations/0002_ledger.sql adds ledger_entries with an identity-column
sequence for exact append order and no UPDATE/DELETE grant for trf_app.
src/target_revenue/ledger.py: append_entry() rejects caller-supplied
previous_entry_hash/signature, enforces per-Licensor phase ownership,
serializes concurrent appends via pg_advisory_xact_lock, computes the
chain tip and signs with the Trust Service instance's own Ed25519 key
(service/keys.py), reusing validation.py's checks unchanged. Adds
POST/GET /phases/{id}/ledger and an unauthenticated GET /public-key.
Also fixes a route-ordering bug found while wiring this in: phase IDs
never needed the {phase_id:path} converter (they contain colons, not
slashes), and its greedy matching was swallowing /ledger-suffixed
paths into the plain GET /phases/{id} route.
tests/test_ledger_hosting.py (8 Docker-gated tests) exercises hash-chain
linkage, forged-field rejection, cross-Licensor isolation, currency and
duplicate-id rejection, DB-privilege enforcement, signature
verification via the public-key endpoint, and the task's own
highest-priority property: append -> export -> offline fold reproduces
the exact expected Development/Remission Credit and Outstanding Target.
Adds migrations/0001_registries.sql (licensors, phase_manifests,
extensions tables; trf_app role with no UPDATE/DELETE grant on either
table, canonicalization only via a SECURITY DEFINER function), and
src/target_revenue/registry.py + service/app.py: a thin FastAPI layer
wrapping the existing validation.py checks with persistence and
per-Licensor token auth, adding no new validation logic per ADR-0002.
New optional service/service-dev dependency groups keep the core
offline library dependency-free. tests/test_registry_hosting.py (7
tests, Docker-gated, auto-skip otherwise) spins an ephemeral disposable
Postgres container and verifies registration, rejection, duplicate/
unknown-token handling, extension canonicalization, and two explicit
database-privilege checks that the app role cannot bypass the
append-only/governance-gated guarantees.
Maintainer (Bernd) accepted 2026-07-29 with no changes requested.
T03-T08 may now build against PostgreSQL + per-Licensor API tokens +
railiance-cluster hosting + Python/src/target_revenue reuse.
Proposes PostgreSQL with database-enforced append-only guarantees,
per-Licensor API tokens decoupled from the existing Ed25519 entry
signatures, and railiance-cluster's existing k3s/GitOps baseline for
hosting rather than new infrastructure, reusing src/target_revenue/
directly behind a thin HTTP layer. Task left todo per the human-accept
gate policy already applied to ADR-0001.
Elaborates framework PRD FR-8/9/10 for a hosted, multi-tenant service:
stakeholders, which Stage 0 guarantees (WP-0002) carry over unchanged
vs. which single-Phase/no-auth/no-tenancy constraints must lift and
onto which task (T03-T08), functional/non-functional requirements, and
an API surface sketch. Flags that no current task owns hosting the
Breach/Compliance Record component added by License V1C1 SS7.4.
Maintainer decision (2026-07-29): full specialist legal review of the
TRSL/CUA is postponed until the framework moves out of beta, given
limited legal/commercial exposure during build/alpha. WP-0004-T10 and
WP-0005-T10 synthesize their jurisdiction research into adopted alpha/beta
working defaults (governing law -> arbitration at a neutral seat,
liability cap, data protection minimal-collection practice, and the
Enforcement Network's fee mechanics) rather than full resolution, and are
accepted on that basis. Propagates the decision to the License/CUA V1C1
Appendix A tables and status banners, SCOPE.md, CONTRIBUTING.md, the
WP-0008-T05 go-live gate, and README.md.
With WP-0001/0002/0003 finished, PRD Phase 4b (hosted Trust Service) is
unblocked per SCOPE.md's own sequencing rule, and the midterm goal shifts
from framework design to practical application: governing and monetizing
repos across the coulomb Forgejo org's product lines (coulomb-loop,
net-kingdom, helix-forge, the railiance-* family).
- TREV-WP-0006: Trust Service reference implementation (PRD Phase 4b).
Eight tasks from PRD to conformance-tested hosted service, explicit that
it builds infrastructure only - no real payments or Phase tracking.
- TREV-WP-0007: Degeneration policy finalization (PRD Phase 5) and the
full canonical monetization profile catalog (remainder of Phase 3) -
pilot Phases can't responsibly launch on the placeholder pilot policy
and one-line profile defaults alone.
- TREV-WP-0008: Governance formalization (PRD Phase 7) and pilot rollout
preparation. Forces a real design decision the framework never had to
answer while single-repo-hypothetical: who is "the Licensor" across four
independent product lines. Produces draft, non-binding Phase Manifests
as worked examples for one repo per product line, and a CLA draft.
All three explicitly preserve SCOPE.md's existing "no production Phases
until legal review" guardrail rather than overriding it under pressure to
monetize real repos: WP-0008-T05 is a dedicated, human-gated go-live
decision, and no other task in any of the three workplans is permitted to
authorize a real Phase, real Commercial Entitlement sale, or real
Development Credit tracking.
Updates SCOPE.md (new Stage 0/Stage 1 maturity table, revised out-of-scope
table distinguishing "infrastructure in scope" from "going live still
gated"), PRD roadmap (Phase 4b/5/7 now active, pointing at the new
workplans), and README's active-work table accordingly.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Bernd reviewed all four extracts (TargetRevenueFrameworkCore.md,
PhaseManifestSpecification.md, TargetLedgerSpecification.md,
MonetizationExtensionSpecification.md) plus cross-links and open-question
coverage. Six-item checklist complete: one real fix (§1.11's extension-
redefinition list had drifted broader than concept §7.11's closed list),
one polish pass (PRD/CONTRIBUTING cross-link symmetry), four items
confirmed with no changes needed. Marks WP-0003-T06 done and the WP-0003
workplan finished (all 6 tasks complete).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Per reviewer request (polish only, item 5): added the same "ultimate
source / day-to-day reference" dual-citation to the PRD header's
Terminology alignment line, matching README/TSD/CONTRIBUTING. Named all
three other normative extracts (PhaseManifestSpecification.md,
TargetLedgerSpecification.md, MonetizationExtensionSpecification.md) in
CONTRIBUTING.md's Terminology section, which previously named only
TargetRevenueFrameworkCore.md - now symmetric with README's full
four-document table.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Verified the six-field extension contract matches concept §12's YAML
verbatim, the core-term redefinition list matches (consistent with the
item 1 fix), registered/canonical wording matches concept §12.1-§12.2, and
the six canonical candidates match concept §12.2's list in the same order
with product-ideation/general-consulting honestly labeled as not yet
fixture-backed rather than implied complete.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Verified three reviewer notes against the actual spec and schema files:
Rule 1's bare "Required" wording vs longstop_at's "Required for Stage 0"
tier label reads unambiguously given §4 and the schema; degeneration_policy
is correctly plain Required with Q7 (which pilot policy) appearing only in
the schema field description, not as a tier qualifier; target_basis's
optional-object-with-Recommended-subfields structure matches the schema
exactly. All three confirmed as non-issues, not drift.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
WP-0003-T06 review finding: §1.11 paraphrased concept §7.11's closed
extension-redefinition list (Phase, Initial Target, Development Credit,
Remission Credit, Outstanding Target, Conversion Event, Future License) as
"any term in this section" - silently broadening the constitutional
boundary to also cover Milestone Release, Target Multiple, Trust Service,
and Monetization Profile/Extension itself. This created an inconsistency
with MonetizationExtensionSpecification.md §3, which already carried the
concept's narrower list correctly, and would have left the extract and its
sibling document silently disagreeing on what an extension may not touch.
Corrected §1.11 to quote the closed list verbatim, matching the concept,
MonetizationExtensionSpecification.md, TSD §5, and PRD FR-4 (all four of
which already had it right). Whether the broader rule might be desirable
is a separate design question from this faithfulness fix, and is not
addressed here.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Found while preparing WP-0003-T06 for review: §5's prose still named the
unsplit administrative-correction type (renamed to
administrative-correction-development/-remission earlier this session) and
incorrectly implied both admin-correction types require a reverses
pointer, when only credit-reversal and remission-correction do.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
