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.
the-custodian: TRSL applied per explicit maintainer confirmation
(superseding its prior Proprietary and Confidential license) - all ~90
repos now have TRSL.
executor-sandbox: local ~/executor-sandbox directory turned out to be
a stale, disconnected clone (unrelated git history, no origin remote
configured at all) - the real Forgejo repo has entirely different
content (a rein-aharness smoke-test target). Worked against a fresh
clone of the real repo instead: established INTENT.md/SCOPE.md from
its actual observed purpose and applied TRSL, committed/pushed
directly to coulomb/executor-sandbox.git.
executor-worker: confirmed retired per its own README - adopted into
agent-harness (2026-07-17), which was itself later renamed
rein-aharness (glas-harness ADR-001, 2026-07-26). No
coulomb/executor-worker or coulomb/agent-harness repo exists on
Forgejo; rein-aharness is already the live, deployed successor.
Whether to still create a Forgejo repo for the retired prototype's
history is left as an open question, not decided unilaterally.
history/260730-ExecutorRepos-ArchitectureFindings.md records the full
architecture map verified against each repo's own SCOPE/README/ADRs:
activity-core -> issue-core -> glas-harness (router) -> rein-aharness/
rein-openweights (concrete backends) -> llm-connect (adapter engine),
sand-boxer (isolation, consumed by glas-harness), kaizen-agentic
(personas/memory, "prepare" not "execute"). Flags phase-memory's
relationship to kaizen-agentic/agentic-resources as unconfirmed, and
agentic-resources' own SCOPE.md as still an unrefined auto-generated
placeholder.
specs/TargetRevenueControlPlaneConcept.md: an interactive UI over the
hosted Trust Service for the binky tenant, prioritizing interactive
Development Credit entry creation. Flags the actual new design gap
WP-0006 didn't need to solve: one Licensor token vs. multiple human
users needing individually attributable actions - recommends the
Control Plane hold the Licensor token server-side and layer its own
human-user auth/audit log in front, rather than requiring a WP-0006
auth schema change, while leaving the choice to a human gate (T02).
specs/DevelopmentEffortCalculatorConcept.md: turns four metric
families (human interaction time via commit-clustering, workplan/task
volume, file/line complexity, AI token cost via the state hub's
get_token_summary) into target_basis values feeding the framework's
own existing Initial Target formula - not a new formula. Presents two
combination strategies (labor-cost-anchored vs. composite-index) as
alternatives for a human gate (T01) rather than picking one.
workplans/TREV-WP-0009-control-plane-and-effort-calculator.md: 5 tasks
(two human-gated formula/rights decisions, two implementation tasks,
one task to apply the calculator to the real candidate repos already
identified in WP-0008). Explicitly does not declare any real Phase -
both deliverables feed WP-0008-T05's own gate, they don't bypass it.
Maintainer decision, 2026-07-29/30: adopts TRSL V1C1 as the preliminary
governing LICENSE across every repo in the coulomb Forgejo org,
confirmed explicitly as "every repo, no exceptions" including
target-revenue itself and internal tooling repos. This is a
license-text adoption, not a Phase declaration - no Initial Target,
Trust Service registration, or Development Credit tracking exists for
any repo as a result. WP-0008-T05 (real Phase go-live) remains todo
and unaccepted.
Applies TRSL to this repo's own LICENSE (self-referential wording,
since target-revenue is the canonical source) and updates
pyproject.toml's license field from MIT-0 to TRSL-0.1.
history/260730-TRSL-OrgWideLicenseRollout.md is the full execution
record: ~90 repos adopted successfully, 2 committed locally only (no
git remote configured: executor-sandbox, executor-worker), and one
explicitly flagged exception (the-custodian - carried a pre-existing
proprietary/confidential license, deliberately not touched pending
separate confirmation, not silently folded into the blanket
instruction).
scripts/rollout/LICENSE.trsl-v1c1 is the deployed template used across
all repos (operative legal text only, points back to this repo's
specs/TargetRevenueSourceLicense-V1C1.md for the full candidate-status
banner and Appendix A rather than duplicating it ~90 times).
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.
Maintainer (Bernd) accepted 2026-07-29: trsl:policy:linear-longstop-v0
is confirmed as the degeneration formula for the first pilot cohort,
per T01's recommendation - already implemented/tested, pilot-ready
today. progress-paused-longstop-v1 remains the named next iteration,
not required before WP-0008's pilot Phases proceed. Updates
OpenQuestions-WorkingDefaults.md Q7 from "working default" to
"Adopted 2026-07-29." All 4 WP-0007 tasks now done; workplan finished.
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.
