Accept WP-0008-T05 for trsl:phase:info-tech-canon-service-surface
(history/260805-T05-GoLive-info-tech-canon.md). Finish WP-0013 remission
automation and WP-0014 extension/breach/attestation Control Plane UI.
Update SCOPE, README, and pilot-candidate notes for pilot Stage 1.
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.
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.
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.
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.
