migrations/0007_forgejo_hubs.sql: table forgejo_hubs, auto-populated
via a BEFORE INSERT trigger on phase_manifests that reads repo_hub/
repo_hub_uri straight out of the manifest JSONB (no top-level columns
needed). ON CONFLICT DO NOTHING -- a hub already seen is left alone;
correcting a URI is a SECURITY DEFINER governance action
(correct_forgejo_hub_uri), not a plain UPDATE, matching every other
governance-action pattern in this project. Thin Python wrappers added
to registry.py.
tests/test_forgejo_hubs.py (6 Docker-gated tests) and
tests/test_reference_docs.py (13 tests, no Docker needed -- smoke-tests
every real specs/policies/specs/profiles/ file, not just the two
exercised incidentally by T03's Control Plane tests).
All seven WP-0015 tasks done; workplan marked finished. Final suite:
94 passing offline, 183 passing under the service extras venv. No
stray Docker containers left running.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
New service/reference_docs.py renders specs/policies/*.md and
specs/profiles/*.md read-only at request time via a small markdown
library (added markdown + PyYAML to the service extras) -- not a
static-build pipeline, matching the WP-0012-T03 decision to skip
state-hub's heavier Observable Framework pattern.
One parameterized route, GET /reference/{kind}/{slug}, covers both
addendum URL shapes. Discovered phase_detail.html's Status table never
displayed the degeneration_policy id at all -- added that row (with
the reference link) rather than wiring a link with nothing to attach
it to. phase_new.html gets a plain link next to the field.
Deliberately did not wire extension-id links into the UI in this task
-- extension ids don't appear anywhere in the Control Plane today
(that's WP-0014's gap, not this one's to expand).
6 new Docker-gated tests. Full suite: 94 passing offline, 164 passing
with Docker (up from 158).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Schema: phase.milestone_release gains required repo_hub/repo_hub_uri/
repo_id/repo_name; phase gains optional base_phase_id. Backfilled the
golden phase-001 fixture (placeholder values, it's synthetic) and the
three real pilot-candidate manifests with actual Forgejo repo ids
confirmed live (net-kingdom=67, vergabe-teilnahme=62,
info-tech-canon=47, all coulomb/*).
Discovered along the way: the schema change alone would have broken
the existing Control Plane registration form, since nothing collected
the four new fields. Fixed inline rather than leaving it broken
between tasks -- this also completes T04's ledger UI change (drop the
hand-typed ledger input, auto-compute /phases/{id}/ledger, add a
drill-down reference link on phase_detail.html) since both changes
touch the same form/route.
Full suite: 94 passing offline (was 84), 158 passing with Docker
(was 146).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
wn-input/wn-select/wn-button aren't form-associated custom elements —
their real <input>/<select>/<button> live inside shadow DOM, invisible
to an ancestor <form>. Clicking Sign In (or any wn-button[type=submit])
silently did nothing, and even a submitted form would have carried none
of the field values. Bridges both gaps generically in base.html without
touching the vendored library: mirrors each shadow-DOM control's live
value into a hidden native input on submit, and explicitly calls
form.requestSubmit() on wn-button[type=submit] clicks.
Reported by the user clicking Sign In in the running local instance —
missed by test_control_plane_app.py because TestClient POSTs directly
and never exercises real button clicks or shadow DOM.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Builds the Control Plane's browser UI (login, dashboard, Phase
registration, Development Credit entry/proposal/review, credential
admin, audit log) as a FastAPI + Jinja2 app over the already-finished
T03 backend, rather than from scratch — whynot-design's Lit web
components are vendored as static assets (source commit 4b62cffc,
v0.4.1), with lit itself resolved via an esm.sh CDN import map.
Session auth re-checks the credential token against the database on
every request rather than trusting the session cookie's cached rights,
so a mid-session revocation takes effect immediately.
9 new Docker-gated HTTP-level tests via FastAPI's TestClient (no
browser-automation tool available, so real rendering of the <wn-*>
components was never visually verified). All four WP-0009 tasks are
now done; workplan marked finished.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
migrations/0006_control_plane.sql: control_plane_audit_log (append-only,
no UPDATE/DELETE for trf_app) and control_plane_proposed_entries (the
Contributor tier's "propose, don't append" workflow from concept §2) -
review decisions go through a review_proposed_entry() SECURITY DEFINER
function, same governance-action pattern as
set_extension_status/revoke_credential, not a direct UPDATE.
src/target_revenue/control_plane.py is the enforcement layer concept
§2 called for: register_phase/append_development_credit require
Operator+; propose_ledger_entry requires Contributor+ and stores a
pending proposal without touching the real Ledger; approve_proposed_entry
(Operator+) appends it under the *reviewer's own* credential/attribution
(not the original proposer's - the reviewer is who's authorizing it into
the real Ledger, while the proposer stays on record in the proposal row
and audit log); reject_proposed_entry (Operator+) discards it. issue_/
revoke_user_credential (Admin+) wrap registry.py's T02 functions with
the same rights check and audit logging. Every action funnels through
record_audit_event, independent of the Trust Service's own signed
records.
tests/test_control_plane.py (12 tests): rights enforcement at each
tier boundary, the full propose -> approve -> appended-under-reviewer
flow, propose -> reject -> nothing appended, double-review rejection,
audit log content/attribution, DB-level UPDATE rejection on both new
tables. Full suite: 84 offline (unchanged), 53 with Docker (up from
41); no stray containers left running.
migrations/0005_licensor_credentials.sql: licensors can now hold
multiple rows per licensor_id (credential_label, rights tier,
issued_by, revoked_at). Real structural finding: licensor_id couldn't
simply become non-unique, since phase_manifests, extensions, and
breach_records all FK to licensors(licensor_id), which only worked
because that column used to be unique. Introduced licensor_identities
(one row per tenant) as the new FK target for all four tables, with an
ensure_licensor_identity trigger auto-creating the identity on first
credential insert - so existing code (including every earlier test
fixture) needed no changes.
registry.py: Licensor gains credential_label/rights; RIGHTS_TIERS +
has_right() ordinal helper (enforcement is Control Plane's job, T03/
T04, not this task's); issue_sub_credential/revoke_sub_credential
(revocation via a SECURITY DEFINER function, matching
set_extension_status's existing pattern - trf_app has no UPDATE grant
on licensors); authenticate() rejects revoked credentials identically
to unrecognized ones.
Attribution scoped honestly: ledger_entry.schema.json stays unmodified
(frozen Stage 0 surface, additionalProperties:false) - per-entry human
attribution is a hosting-layer-only column
(ledger_entries.submitted_by_token, ledger.get_ledger_attribution()),
recorded alongside but never inside the signed entry payload. Narrower
than "the signature names the human," but exactly the "(or an
accompanying attributable field)" alternative this task's own
description anticipated.
All four Docker-gated test files that append Ledger entries needed
migration 0005 added (append_entry's INSERT now references the new
column). New tests/test_licensor_credentials.py (8 tests): multi-
credential resolution, duplicate-label rejection, revocation and its
idempotence, invalid-rights rejection, the has_right helper, per-entry
attribution recorded and not leaking into exported ledger JSON, and
DB-level UPDATE rejection. Full suite: 84 offline, 41 with Docker (up
from 30); no stray containers left running.
Adds since/until date-range scoping to cluster_commit_hours() and
workplan_task_counts() (threaded through calculate_target_basis()),
needed whenever a candidate is one bounded workplan within a repo
whose overall history spans much more (net-kingdom, railiance-apps)
rather than the whole repo being the candidate (vergabe-teilnahme,
info-tech-canon).
Fixes a real bug found along the way: workplan_task_counts() only
scanned the top level of workplans/, missing net-kingdom's
workplans/archived/ convention entirely - silently reported zero
finished workplans for NK-WP-0002, which lives there. Fixed to scan
recursively; added a regression test.
Updates all three draft pilot-candidate manifests with calculator-
derived target_basis/initial_target values, replacing the hand-picked
placeholders:
net-kingdom-local-identity: 200,000 -> 10,000 EUR (floor + sanity warnings)
railiance-vergabe-teilnahme: 3,500,000 -> 648,800 EUR (no warnings)
info-tech-canon-service-surface: 2,500,000 -> 141,800 EUR (sanity warning)
history/260730-EffortCalculator-CandidateApplication.md records full
derivation, warnings, and the judgment calls made explicit rather than
silently picked (date-scoping windows; measuring vergabe-teilnahme's
own repo rather than railiance-apps' deployment-only wiring, with both
figures shown). Still draft/non-binding - WP-0008-T05 unaffected.
5 new tests (20 -> now covering since/until scoping and the
archived-subdirectory fix). Full suite: 84 passing offline.
src/target_revenue/effort_calculator.py implements Candidate A
(labor-cost-anchored, accepted T01): commit-timestamp session-gap
clustering for human interaction time, workplan/task-volume counts via
direct workplans/ directory parsing (no state-hub dependency, works
uniformly on any repo using this repo's own convention), file/line
counts with generated/vendored-path exclusion, and caller-supplied
token-cost pricing. estimate_target_basis() combines these and returns
a derivation dict (every input shown) plus a warnings list - never a
black-box dollar figure.
1-day manual-work floor, as requested: any raw commit-clustered
estimate below 1.0 day is floored and flagged with a warning that this
is very likely a measurement gap (commit-clustering is a floor
estimate by design) that should usually be compensated for by manual
override, not trusted at face value. A second, independent
sanity-check warning fires when finished-workplan/task volume is
substantial but the time estimate is still low, even above the floor -
demonstrated live against target-revenue's own history (7 finished
workplans, 57 tasks correctly flagged a 2.38-day estimate as
under-counted).
scripts/effort_calculator_cli.py: CLI wrapper printing JSON, following
the same offline-first, no-Phase-declaration pattern as
scripts/trf_onboard.py. tests/test_effort_calculator.py (15
deterministic tests, throwaway git repos/tmp_path fixtures) covers
commit clustering, workplan/task parsing, size-metric exclusion,
token-cost pricing, the floor-and-warning behavior, the sanity-check
warning, and an end-to-end smoke test. No new hard dependency.
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.
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.
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.
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.
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>
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>
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>
