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.
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 (Bernd) accepted 2026-07-30: four rights tiers
(Viewer/Contributor/Operator/Admin) confirmed as proposed. Selected
option (a) - per-human sub-credentials at the Trust Service layer -
over this concept's own recommended option (b), meaning the Trust
Service's signed ledger records can attest to the specific human who
acted, not merely the binky tenant.
This adds a real, firm prerequisite the workplan didn't have before:
extending WP-0006's already-finished licensors/token auth model.
Restructured T02 (was: backend+audit) into T02 (WP-0006 auth
extension, new) + T03 (Control Plane backend, renumbered) + T04
(interactive UI, renumbered) to keep that scope visible as its own
task rather than folding it silently into backend work.
Maintainer (Bernd) accepted 2026-07-30: estimated_effort_days/daily_rate
driven directly by commit-clustered human interaction time;
approved_direct_costs from real metered AI token cost
(get_token_summary); workplan/task-volume and file/line-size metrics
serve only as a sanity check on the human-time estimate, never their
own dollar figure; Target Multiple remains a human classification.
Candidate B recorded as the considered, not-adopted alternative.
The two deliverables have independent formula/rights decisions and
implementation arcs; keeping them in one workplan blurred that they
can be reviewed and sequenced separately, even though the Control
Plane's Phase-registration flow is expected to consume the
Calculator's output once both exist.
WP-0009 (Target Revenue Control Plane): keeps the original workstream
ID, retitled and re-tasked to 3 focused tasks - rights-model decision
(human gate), backend auth/audit layer, interactive UI flows.
WP-0010 (Development Effort Calculator, new): 3 tasks - formula
decision (human gate), implementation, application to the real
candidate repos already identified in WP-0008. No real Phase
declaration in either workplan's scope.
Updated both concept documents' workplan cross-references and
README.md's summary table accordingly.
Maintainer decision, 2026-07-30: rein-aharness is executor-worker's
real, live successor - no coulomb/executor-worker Forgejo repo will
be created. Local directory moved to
archive/260717-executor-worker-retired/ (timestamped to its actual
retirement commit date) to get it out of the active workstation
directory listing; git history preserved intact by the move.
