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.
Reopens WP-0006 (status: active) to track the gap T01's Trust Service
PRD flagged: the Breach/Compliance Record component (TSD §4.1, added
alongside License V1C1 §7.4) postdates WP-0002 and was never assigned
to T03-T08. Scopes it: publish alleged/determined breach status
without adjudicating, default anonymized with CUA-§9-gated named
disclosure, append-only per the existing pattern, reusing the
per-Licensor token model for writes.
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.
