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>
specs/policies/linear-longstop-v0.md extracted from
OpenQuestions-WorkingDefaults.md Q7's prose, with policy_id/title
frontmatter -- Q7 now records only the adoption decision, pointing at
this file for the formula itself.
Six specs/profiles/*.md files extracted from
CanonicalMonetizationProfiles.md's per-profile sections (#1-6), each
with extension_id/title frontmatter matching the ids already used in
real Phase Manifests. CanonicalMonetizationProfiles.md keeps the
cross-profile summary and non-goals sections, now pointing at the
extracted files instead of containing their content.
DevelopmentEffortCalculatorConcept.md gets calculator_id/revision/title
frontmatter for consistency, no move (already conformed as one file per
model). Checked for stale cross-references before editing -- nothing
in the repo links to the removed section anchors.
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>
specs/PhaseProvenanceSpecAddendum.md accepted 2026-08-03. Implementation
filed as its own workplan (TREV-WP-0015), seven tasks mapping 1:1 to
the addendum's sections rather than repeating field shapes/rationale:
schema change, specs/policies/ + specs/profiles/ extraction, Control
Plane reference-rendering routes, ledger UI change, forgejo_hubs
migration, backfilling the three example manifests, and tests/closeout.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
specs/PhaseProvenanceSpecAddendum.md synthesizes T02-T04's accepted
decisions into one reviewable document: the phase_manifest schema diff
(repo_hub/repo_hub_uri/repo_id/repo_name, base_phase_id), the
specs/policies/ + specs/profiles/ extraction with concrete file lists
and frontmatter shapes, the ledger UI change, a forgejo_hubs migration
sketch for the hosted hub registry, the three-example-manifest backfill
plan, and a suggested implementation task breakdown.
This is a proposal only, not yet accepted for implementation -- per
the maintainer's own established sequencing, this is the document to
discuss before any of it is filed as its own workplan. All five
WP-0012 tasks are done; workplan marked finished.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Registration form drops the ledger input entirely -- Trust Service
auto-computes the canonical /phases/{id}/ledger reference at
registration time, no human types it in v0. Schema field itself is
unaffected (still present, still federation-ready). Drill-down shows
only the raw reference + a live-data link when it resolves to this
instance; the existing Ledger entries table on phase_detail.html is
untouched and stays exactly as prominent.
All four T02-T04 decisions now feed T05's spec addendum draft.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Checked the maintainer's specific state-hub Reference mechanism before
deciding rather than assuming from the earlier discussion: it's a
dashboard/src/docs/*.md corpus built via Observable Framework into
static HTML, opened standalone or in a "?" context-help overlay. Real,
but a materially heavier static-site pipeline than this repo has or
needs. Decided to carry the spirit (markdown spec -> rendered read-only
view, linked from wherever the id appears) via a small server-side
markdown render route instead, matching the existing lightweight
FastAPI+Jinja2 stack.
Decided: new specs/policies/ and specs/profiles/ subdirectories, one
file per policy/profile, id+revision frontmatter, git's own history as
the audit trail (no new versioning infrastructure). Calculator concept
doc already conforms as-is. No files moved yet -- deferred to after
T04/T05 per the same implementation-after-addendum sequencing used for
T02.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Confirmed live against forgejo.coulomb.social before deciding rather
than assuming: repo ids are real and stable (target-revenue is 103),
but no instance-level hub identity exists (no nodeinfo endpoint), so
the hub identifier has to be minted, not read from Forgejo.
Decided: milestone_release gains required repo_hub/repo_hub_uri/
repo_id/repo_name; phase.base_phase_id is optional, absent for a
first-ever Phase. The hub-to-URI mapping is hosted Trust Service data
(a new table, parallel to licensor_identities), not a file in this
framework repo, per the maintainer's steer that target-revenue must
stay the generic framework rather than carry a specific deployment's
repo list. Backfilling the three example manifests is deferred to
after T03/T04/T05, since the schema change is shared across all three.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
specs/PhaseLifecycleUseCases.md enumerates all nine use cases from the
workplan systematically, grounded in the actual schema, code, and the
three real pilot-candidate manifests rather than abstractly. Two
findings surfaced beyond the original scope: first-Phase and
successive-Phase provenance turn out to be one shared modeling
question (both feed T02), and breach-record publication already has a
decided Operator+ rights tier per the Control Plane concept doc while
extension registration/canonicalization does not — recorded as an
explicit open question for WP-0014-T01 instead of an assumption.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
TREV-WP-0012 is the modeling-only workplan requested after using the
Control Plane UI surfaced real gaps: Phase registration has no
structured repo/provenance fields, the ledger URI is hand-typed, and
degeneration policies are opaque ids with no reviewable spec behind
them. It produces a use-cases document and a discussable spec addendum
before any schema/UI implementation.
Two of the use cases uncovered while scoping this turned out to be
bigger than documentation gaps and are tracked as their own workplans
per that direction: TREV-WP-0013 (nothing currently computes or writes
Remission Credit ledger entries at all) and TREV-WP-0014 (Extension
Registry, Breach Record, and Conversion Attestation backends already
exist from WP-0006 but have no Control Plane UI).
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>
Deploys the Trust Service and Control Plane UI to Railiance
infrastructure-as-code behind revenue.coulomb.social. T01 is a human
decision gate on deployment pattern (own-repo k8s/railiance vs.
railiance-apps chart, one process vs. two, CNPG database, OpenBao
secrets, subdomain/TLS, credential bootstrap) before any manifest work
starts. Deployment is explicitly scoped as infrastructure delivery,
not a Phase go-live decision (that remains WP-0008-T05).
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.
