Commit graph

13 commits

Author SHA1 Message Date
b0f61b2d8b Add info-tech-canon as first dry-run pilot candidate, exercise onboarding routine
Maintainer chose info-tech-canon (outside the original four product
lines) as the actual first repo to build up the practical
Phase-declaration routine on, explicitly confirmed as a dry run, not a
T05 go-live decision.

Adds a third draft, non-binding manifest
(examples/pilot-candidates/info-tech-canon-service-surface/): the
cumulative service surface across ITC-WP-0001-0012 (all finished),
Product-defining (100x). Flags a notable complication rather than
smoothing it over: this repo's current LICENSE is already MIT-0, so a
real Phase here would mean replacing an already-open license with
restricted pre-conversion TRSL terms - a materially different step
than the other two candidates.

Exercised the full onboarding routine end-to-end against a real,
ephemeral local instance of the hosted Trust Service (Docker Postgres,
migrations applied, binky Licensor token seeded, uvicorn running the
actual service/app.py): register-phase -> append-entry -> status all
worked via scripts/trf_onboard.py exactly as
specs/TrustServiceOnboarding.md describes, no code changes needed.
Dry-run infrastructure torn down afterward; only the draft manifest
files persist.
2026-07-29 23:15:42 +02:00
9886742fa8 Advance WP-0008: governance, candidate survey, pilot manifests, CLA draft
T01: specs/TRSL-Governance.md. Resolves the Licensor-identity question
(maintainer decision, 2026-07-29): a single shared Licensor, Binky
Hedgehog GmbH, operating as the binky tenant, across all four product
lines - not per-product-line. Unblocks (does not itself resolve) the
License/CUA arbitral-institution selection now that the Licensor's own
jurisdiction is known. Tables versioning/extension-governance/operator-
governance status per concept §20, naming open items (compatibility
rules, deprecation criteria, conflict-of-interest rule, key-rotation
history) rather than silently assuming them solved.

T02: specs/PilotPhaseCandidateSurvey.md. Direct repo inspection (hub
had no goal data for three of four product lines) plus an Explore-agent
survey of all ten railiance-* repos. Two defensible candidates found:
NK-WP-0002 Local Identity (net-kingdom, Incremental 10x) and
vergabe-teilnahme (railiance-apps, Product-defining 100x, the only
genuinely product-shaped deliverable across ten railiance-* repos).
coulomb-loop and helix-forge have no candidate, for stated principled
reasons (internal tooling; pre-implementation-stage, respectively).

T03: examples/pilot-candidates/ - draft, non-binding Phase Manifests
for both real candidates, trsl:phase:draft-* ids, empty ledgers,
schema-validated, explicit README stating nothing here is authorized
to go live.

T04: specs/TRSL-ContributorLicenseAgreement-Draft.md, implementing the
CLA-not-assignment recommendation from
history/260729-TRSL-ContributorRights-Research.md - narrowly scoped to
the current Phase's TRSL terms plus its already-declared Future
License at Conversion, same preliminary-candidate treatment as the
License/CUA V1C1 documents. CONTRIBUTING.md updated to point at it
while keeping the external-contribution block in effect until accepted.

T05's precondition list updated to reflect what's now resolved, still
left todo by design pending the maintainer's own go-live decision.
2026-07-29 22:52:52 +02:00
58a4dd1db2 Advance WP-0007: degeneration research, profile catalog, canonicalization checklist
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.
2026-07-29 22:31:19 +02:00
b7b985d96d Implement hosted Breach/Compliance Record publication (WP-0006-T09)
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.
2026-07-29 22:23:41 +02:00
151ed3e97c Add hosted conformance suite and close WP-0006 (T08)
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.
2026-07-29 22:07:39 +02:00
ee4cf14cbc Define and implement multi-repo onboarding mechanism (WP-0006-T07)
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.
2026-07-29 22:00:34 +02:00
28f0f429b2 Implement hosted Conversion Attestation publication (WP-0006-T06)
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.
2026-07-29 21:50:02 +02:00
dfc1d90c28 Implement public metrics service (WP-0006-T05)
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.
2026-07-29 21:42:52 +02:00
5064815e77 Implement hosted Target Ledger append API (WP-0006-T04)
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.
2026-07-29 21:34:27 +02:00
7e0c62a8b5 Implement hosted Phase/Extension Registry (WP-0006-T03)
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.
2026-07-29 21:03:52 +02:00
55a1756f7c Merge spec/ into specs/: one specs directory for the whole repo
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>
2026-07-29 10:22:14 +02:00
2b675c11ad Split administrative-correction into typed development/remission corrections
Resolves the WP-0003-T06 review flag: the single administrative-correction
ledger entry type had an unstated fold-side effect (concept §17 names the
type but never says which side of the target it corrects). Maintainer chose
option (a) — split into administrative-correction-development and
administrative-correction-remission so the corrected side is explicit in
the type name rather than an implicit library default.

- schemas/ledger_entry.schema.json: enum split, no other behavior change.
- src/target_revenue/fold.py: each new type maps to its named side only.
- specs/TargetLedgerSpecification.md, TechnicalSpecificationDocument.md
  §3.2, ProductRequirementsDocument.md FR-5: updated to the split types.
- tests/test_ledger_fold.py: dedicated coverage for both new types plus a
  regression test that the old unsplit type name is now rejected.

spec/TargetRevenueLicenseConcept.md §17 is left unedited — its entry-type
list is explicitly non-exhaustive ("may include"), so this specializes
rather than contradicts it.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-29 09:16:22 +02:00
57c7111cbc Implement TREV-WP-0002 Stage 0 foundation: schemas, pure fold, golden Phase
Delivers the offline runnable specification foundation for the Trust Layer
(TSD §3-§6), not a hosted Trust Service:

- JSON Schemas for Phase Manifest, Ledger Entry, Extension Contract, and
  Conversion Attestation, encoding the Stage 0 working defaults (Q3 future
  license enum, Q6 single-currency Phases, Q8 required longstop_at).
- src/target_revenue: pure Outstanding Target fold, SHA-256 hash-chain
  verification, Ed25519 signing helpers, extension conformance checks
  (including a core-term-redefinition heuristic), and conversion detection
  that never requires an attestation document to determine conversion status.
- examples/phase-001: golden Phase package matching the concept doc's
  worked example, generated via scripts/generate_golden_phase.py so the
  hash chain is computed by the library itself, not hand-typed.
- 32 passing pytest tests covering manifest/ledger/extension conformance,
  tamper/reorder detection, and the full lifecycle fold to conversion.
- docs/adr/ADR-0001: proposed (not accepted) Stage 0 stack choice, per the
  WP-0002-T01 human-accept gate — implementation proceeded against the
  proposal as the workplan note permits, but the task stays open.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-28 18:47:29 +02:00