Set up practical implementation workplans (WP-0006/0007/0008)
With WP-0001/0002/0003 finished, PRD Phase 4b (hosted Trust Service) is unblocked per SCOPE.md's own sequencing rule, and the midterm goal shifts from framework design to practical application: governing and monetizing repos across the coulomb Forgejo org's product lines (coulomb-loop, net-kingdom, helix-forge, the railiance-* family). - TREV-WP-0006: Trust Service reference implementation (PRD Phase 4b). Eight tasks from PRD to conformance-tested hosted service, explicit that it builds infrastructure only - no real payments or Phase tracking. - TREV-WP-0007: Degeneration policy finalization (PRD Phase 5) and the full canonical monetization profile catalog (remainder of Phase 3) - pilot Phases can't responsibly launch on the placeholder pilot policy and one-line profile defaults alone. - TREV-WP-0008: Governance formalization (PRD Phase 7) and pilot rollout preparation. Forces a real design decision the framework never had to answer while single-repo-hypothetical: who is "the Licensor" across four independent product lines. Produces draft, non-binding Phase Manifests as worked examples for one repo per product line, and a CLA draft. All three explicitly preserve SCOPE.md's existing "no production Phases until legal review" guardrail rather than overriding it under pressure to monetize real repos: WP-0008-T05 is a dedicated, human-gated go-live decision, and no other task in any of the three workplans is permitted to authorize a real Phase, real Commercial Entitlement sale, or real Development Credit tracking. Updates SCOPE.md (new Stage 0/Stage 1 maturity table, revised out-of-scope table distinguishing "infrastructure in scope" from "going live still gated"), PRD roadmap (Phase 4b/5/7 now active, pointing at the new workplans), and README's active-work table accordingly. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
parent
cdfdd7f6b3
commit
dd7f7d2181
6 changed files with 442 additions and 27 deletions
166
workplans/TREV-WP-0006-trust-service-implementation.md
Normal file
166
workplans/TREV-WP-0006-trust-service-implementation.md
Normal file
|
|
@ -0,0 +1,166 @@
|
|||
---
|
||||
id: TREV-WP-0006
|
||||
type: workplan
|
||||
title: "Trust Service reference implementation (PRD Phase 4b)"
|
||||
domain: infotech
|
||||
repo: target-revenue
|
||||
status: active
|
||||
owner: claude
|
||||
topic_slug: infotech
|
||||
created: "2026-07-29"
|
||||
updated: "2026-07-29"
|
||||
---
|
||||
|
||||
# Trust Service reference implementation (PRD Phase 4b)
|
||||
|
||||
Builds the hosted Trust Service that WP-0002 deliberately deferred: Phase
|
||||
Registry, Extension Registry, hosted Target Ledger, Metrics, and Conversion
|
||||
Attestation publication, serving multiple repos rather than the single
|
||||
offline golden-Phase package. This is the piece explicitly named in
|
||||
`SCOPE.md` §3 as out of scope until now.
|
||||
|
||||
**Unblocked as of 2026-07-29:** `SCOPE.md` §4 rule 2 required (a) WP-0003's
|
||||
core extract deliverables to exist, and (b) working defaults for Longstop,
|
||||
currency, recognition, and minimum evidence to be published, before full
|
||||
Trust Service implementation could start. Both conditions are now met
|
||||
(WP-0003 finished 2026-07-29; `specs/OpenQuestions-WorkingDefaults.md`
|
||||
published since Stage 0). This workplan is the first to actually start
|
||||
that implementation.
|
||||
|
||||
**Why now:** the midterm goal is to govern and monetize the evolution of
|
||||
repos across the `coulomb` Forgejo org's product lines (`coulomb-loop`,
|
||||
`net-kingdom`, `helix-forge`, the `railiance-*` family) — that requires a
|
||||
real, multi-repo-capable Trust Service, not the single-Phase offline
|
||||
library WP-0002 produced.
|
||||
|
||||
**Does not include:** accepting real payments or tracking a real Phase for
|
||||
any production repo — see `workplans/TREV-WP-0008-governance-and-pilot-rollout.md`
|
||||
for the human-gated go-live step. This workplan builds the infrastructure;
|
||||
it does not turn it on for anyone's real money.
|
||||
|
||||
## Trust Service Product Requirements Document
|
||||
|
||||
```task
|
||||
id: TREV-WP-0006-T01
|
||||
status: todo
|
||||
priority: high
|
||||
```
|
||||
|
||||
Produce `specs/TrustServiceProductRequirementsDocument.md`: scope,
|
||||
stakeholders, and requirements for the hosted service, building directly
|
||||
on `specs/TechnicalSpecificationDocument.md` §4 (component architecture)
|
||||
and §3's schemas. Must state explicitly which of WP-0002's Stage 0
|
||||
guarantees (determinism, offline verifiability, no Trust Service discretion
|
||||
over conversion) the hosted service inherits unchanged versus which
|
||||
Stage-0-only constraints (single golden Phase, no auth, no multi-tenancy)
|
||||
it must now lift.
|
||||
|
||||
## Stack and storage ADR (hosted service — distinct scope from ADR-0001)
|
||||
|
||||
```task
|
||||
id: TREV-WP-0006-T02
|
||||
status: todo
|
||||
priority: high
|
||||
human_accept_required: true
|
||||
```
|
||||
|
||||
`docs/adr/ADR-0001-stage0-library-stack.md` explicitly scoped out hosting,
|
||||
storage, and multi-tenancy decisions (its Revisit trigger names this exact
|
||||
moment). Record a new ADR for: storage engine for the append-only Target
|
||||
Ledger at multi-repo scale, authentication/authorization model for Phase
|
||||
Registry writes, and hosting/deployment target — `railiance-infra` and
|
||||
`railiance-cluster` are the existing platform-infrastructure repos in this
|
||||
Forgejo org and are the natural first candidates to investigate, not
|
||||
assumed by default.
|
||||
|
||||
**Human accept gate:** per the same policy as ADR-0001 — agents may draft,
|
||||
must not treat as accepted without explicit maintainer sign-off.
|
||||
|
||||
## Phase Registry and Extension Registry hosting
|
||||
|
||||
```task
|
||||
id: TREV-WP-0006-T03
|
||||
status: todo
|
||||
priority: high
|
||||
```
|
||||
|
||||
Implement hosted versions of the Phase Registry and Extension Registry
|
||||
components (`specs/TechnicalSpecificationDocument.md` §4.1), serving
|
||||
multiple Phase Manifests and extension registrations across repos rather
|
||||
than one golden fixture. Reject non-conformant manifests/extensions at
|
||||
registration, exactly as the Stage 0 validators already do — this task
|
||||
adds multi-tenancy and persistence, not new validation logic.
|
||||
|
||||
## Hosted Target Ledger append API
|
||||
|
||||
```task
|
||||
id: TREV-WP-0006-T04
|
||||
status: todo
|
||||
priority: high
|
||||
```
|
||||
|
||||
Implement an authenticated append API for Target Ledger entries per Phase,
|
||||
preserving WP-0002's append-only, hash-chained, deterministically-foldable
|
||||
guarantees exactly. Any party who can compute the fold offline from an
|
||||
export must get the same Outstanding Target as the hosted service — this
|
||||
is the property to test most aggressively, since it's the one a hosted
|
||||
service could most easily and least visibly break.
|
||||
|
||||
## Metrics service
|
||||
|
||||
```task
|
||||
id: TREV-WP-0006-T05
|
||||
status: todo
|
||||
priority: medium
|
||||
```
|
||||
|
||||
Implement the public metrics set from `specs/OpenQuestions-WorkingDefaults.md`
|
||||
Q9 (Initial Target, cumulative credits, Outstanding Target, conversion
|
||||
status, last checkpoint, Longstop timestamp as mandatory; velocity/forecast
|
||||
as recommended, clearly labeled as forecasts per concept §14.6).
|
||||
|
||||
## Conversion Attestation publication
|
||||
|
||||
```task
|
||||
id: TREV-WP-0006-T06
|
||||
status: todo
|
||||
priority: high
|
||||
```
|
||||
|
||||
Implement Conversion Attestation generation and publication as a hosted
|
||||
service, preserving the non-discretionary rule from
|
||||
`src/target_revenue/conversion.py`: the service publishes evidence of a
|
||||
conversion already true from the Manifest + Ledger, never a precondition
|
||||
for it. Any repo's own tooling must be able to recompute conversion status
|
||||
without querying this service at all.
|
||||
|
||||
## Multi-repo onboarding flow
|
||||
|
||||
```task
|
||||
id: TREV-WP-0006-T07
|
||||
status: todo
|
||||
priority: medium
|
||||
```
|
||||
|
||||
Define and implement how a repo (e.g. `coulomb-loop`, `net-kingdom`,
|
||||
`helix-forge`, a `railiance-*` repo) registers a Phase against the hosted
|
||||
Trust Service: what it commits to its own repo (a Phase Manifest file,
|
||||
per `specs/PhaseManifestSpecification.md`) versus what it submits to the
|
||||
Trust Service (the registration call). Coordinate with
|
||||
`workplans/TREV-WP-0008-governance-and-pilot-rollout.md`, which selects
|
||||
the actual first repos — this task defines the mechanism, not the pilot
|
||||
selection.
|
||||
|
||||
## Conformance test suite at hosted scale
|
||||
|
||||
```task
|
||||
id: TREV-WP-0006-T08
|
||||
status: todo
|
||||
priority: medium
|
||||
```
|
||||
|
||||
Extend WP-0002's conformance suite to run against the hosted service:
|
||||
multiple concurrent Phases across different repos, the golden Phase
|
||||
example replayed through the hosted API rather than only the offline
|
||||
library, and a specific regression test that hosted and offline folds of
|
||||
the same exported ledger always agree.
|
||||
|
|
@ -0,0 +1,93 @@
|
|||
---
|
||||
id: TREV-WP-0007
|
||||
type: workplan
|
||||
title: "Degeneration policy research and canonical monetization profiles"
|
||||
domain: infotech
|
||||
repo: target-revenue
|
||||
status: active
|
||||
owner: claude
|
||||
topic_slug: infotech
|
||||
created: "2026-07-29"
|
||||
updated: "2026-07-29"
|
||||
---
|
||||
|
||||
# Degeneration policy research and canonical monetization profiles
|
||||
|
||||
Finalizes two PRD deliverables that pilot Phases (`workplans/TREV-WP-0008-governance-and-pilot-rollout.md`)
|
||||
cannot responsibly launch without: a degeneration policy beyond the
|
||||
placeholder `trsl:policy:linear-longstop-v0`, and a full worked canonical
|
||||
monetization profile catalog beyond the six one-line defaults already in
|
||||
`specs/MonetizationExtensionSpecification.md` §5.
|
||||
|
||||
**Why this blocks pilot rollout:** every Phase Manifest requires a
|
||||
`degeneration_policy` reference (`specs/PhaseManifestSpecification.md`,
|
||||
Required field) and, in practice, at least one Monetization Extension.
|
||||
Launching real pilot Phases on an admittedly-provisional pilot policy and
|
||||
one-line profile defaults is a real business decision, not a technical
|
||||
blocker — but it should be a *chosen* risk, not an accidental one because
|
||||
this workplan was skipped.
|
||||
|
||||
## Degeneration policy research
|
||||
|
||||
```task
|
||||
id: TREV-WP-0007-T01
|
||||
status: todo
|
||||
priority: high
|
||||
```
|
||||
|
||||
Produce `specs/TargetDegenerationPolicyResearch.md`: survey comparative
|
||||
models (BSL/FSL-style fixed longstop vs. progress-sensitive decay vs.
|
||||
hybrid — `history/260729-TRSL-PriorArt-Survey.md` already has partial
|
||||
groundwork), and resolve concept §13.2's open inputs (progress-sensitive
|
||||
pause on material Development Credit, contributor diversity factors) that
|
||||
`trsl:policy:linear-longstop-v0` deliberately left unresolved per
|
||||
`specs/OpenQuestions-WorkingDefaults.md` Q7.
|
||||
|
||||
## Degeneration formula decision (human gate)
|
||||
|
||||
```task
|
||||
id: TREV-WP-0007-T02
|
||||
status: todo
|
||||
priority: high
|
||||
human_accept_required: true
|
||||
```
|
||||
|
||||
Using T01, propose either: (a) confirming `linear-longstop-v0` as the
|
||||
adopted v1 formula (not merely a Stage 0 pilot default), or (b) a
|
||||
refined/replacement formula. Either way this promotes a working default to
|
||||
permanent-enough-to-launch-pilots-on status, which per `SCOPE.md` §4
|
||||
requires explicit human accept — agents may prepare the recommendation and
|
||||
leave this `todo`.
|
||||
|
||||
## Canonical monetization profile catalog
|
||||
|
||||
```task
|
||||
id: TREV-WP-0007-T03
|
||||
status: todo
|
||||
priority: high
|
||||
```
|
||||
|
||||
Produce `specs/CanonicalMonetizationProfiles.md`: full worked pricing
|
||||
narratives and examples for the six canonical-candidate profiles already
|
||||
named in `specs/MonetizationExtensionSpecification.md` §5
|
||||
(`development-license`, `cost-plus-operations`, `phase-sponsorship`,
|
||||
`service-with-development-allocation`, `product-ideation`,
|
||||
`general-consulting`), plus fixture files for the two not yet
|
||||
fixture-backed (`product-ideation`, `general-consulting`), following the
|
||||
pattern already established in `examples/phase-001/extensions/`.
|
||||
|
||||
## Canonicalization review process (light)
|
||||
|
||||
```task
|
||||
id: TREV-WP-0007-T04
|
||||
status: todo
|
||||
priority: medium
|
||||
```
|
||||
|
||||
Per `specs/MonetizationExtensionSpecification.md` §4, promoting an
|
||||
extension from `registered` to `canonical` "is a documented human/
|
||||
governance action, never automated" — but no document yet describes what
|
||||
that review actually checks. Produce a short (not a full governance
|
||||
framework — that's `workplans/TREV-WP-0008-governance-and-pilot-rollout.md`
|
||||
T01) checklist for canonicalizing the six profiles in this workplan,
|
||||
sufficient to promote them from `registered` to `canonical` status.
|
||||
147
workplans/TREV-WP-0008-governance-and-pilot-rollout.md
Normal file
147
workplans/TREV-WP-0008-governance-and-pilot-rollout.md
Normal file
|
|
@ -0,0 +1,147 @@
|
|||
---
|
||||
id: TREV-WP-0008
|
||||
type: workplan
|
||||
title: "Governance formalization and pilot rollout (coulomb / net-kingdom / helix-forge / railiance)"
|
||||
domain: infotech
|
||||
repo: target-revenue
|
||||
status: active
|
||||
owner: claude
|
||||
topic_slug: infotech
|
||||
created: "2026-07-29"
|
||||
updated: "2026-07-29"
|
||||
---
|
||||
|
||||
# Governance formalization and pilot rollout
|
||||
|
||||
The midterm goal: govern and monetize the evolution of repos across the
|
||||
`coulomb` Forgejo org's product lines — `coulomb-loop`, `net-kingdom`,
|
||||
`helix-forge`, and the `railiance-*` family (`railiance-apps`,
|
||||
`railiance-bootstrap`, `railiance-cluster`, `railiance-enablement`,
|
||||
`railiance-fabric`, `railiance-forge`, `railiance-hosts`, `railiance-infra`,
|
||||
`railiance-master`, `railiance-platform`). This workplan formalizes the
|
||||
governance the framework has been designed around but never actually
|
||||
written down, and prepares (but does not itself execute) the first real
|
||||
Phase declarations.
|
||||
|
||||
**Hard gate, stated up front:** `SCOPE.md` §3 lists "governing third-party
|
||||
product Phases in production" as out of scope "after legal + Stage 0
|
||||
package ready" — i.e., not yet. This workplan's rollout tasks (T03–T04)
|
||||
produce **draft, non-binding** Phase Manifests as worked examples, exactly
|
||||
like `examples/phase-001/` already is. **No real Commercial Entitlement may
|
||||
be sold, no real Development Credit tracked, and no repo's actual License
|
||||
header changed to TRSL, until T05 (the go-live gate) is explicitly
|
||||
accepted** — after TRSL/CUA specialist legal review (`workplans/TREV-WP-0004-global-jurisdiction-research.md` /
|
||||
`workplans/TREV-WP-0005-enforcement-network-research.md` T10 syntheses
|
||||
feed this) and T01 (Licensor governance) are both resolved. Moving fast on
|
||||
T01–T04 must not create pressure to skip T05.
|
||||
|
||||
## Governance document: TRSL-Governance.md
|
||||
|
||||
```task
|
||||
id: TREV-WP-0008-T01
|
||||
status: todo
|
||||
priority: high
|
||||
```
|
||||
|
||||
Produce `specs/TRSL-Governance.md`, per `spec/TargetRevenueLicenseConcept.md`
|
||||
§20 (complexity budget, versioning, extension governance, operator
|
||||
governance). Must resolve one question this rollout makes concretely
|
||||
unavoidable for the first time: **who is "the Licensor"** across four
|
||||
different product lines under one Forgejo org — a single shared Licensor
|
||||
entity for all four (simplest, but conflates genuinely different products'
|
||||
commercial decisions), or a per-product-line Licensor (each of
|
||||
`coulomb-loop`, `net-kingdom`, `helix-forge`, `railiance` declaring its own
|
||||
Phases independently under a shared TRSL/CUA template)? This was never
|
||||
forced while the framework was single-repo-hypothetical; it is now.
|
||||
Also define: change process for the License/CUA templates themselves once
|
||||
multiple product lines depend on them, extension canonicalization review
|
||||
(coordinate with `workplans/TREV-WP-0007-degeneration-policy-and-canonical-profiles.md`
|
||||
T04's narrower checklist), and dispute/conflict-of-interest handling per
|
||||
concept §20.3–§20.4.
|
||||
|
||||
## Repo inventory and Phase-candidate survey
|
||||
|
||||
```task
|
||||
id: TREV-WP-0008-T02
|
||||
status: todo
|
||||
priority: high
|
||||
```
|
||||
|
||||
For each of `coulomb-loop`, `net-kingdom`, `helix-forge`, and the
|
||||
`railiance-*` family: survey current repo goals and status (via the state
|
||||
hub's `get_domain_summary`/`list_domain_repos`/repo-goal tools, or direct
|
||||
repo inspection where hub data is thin) to identify one plausible first
|
||||
Milestone Release candidate per product line — a bounded, recently- or
|
||||
soon-to-be-completed piece of work with a defensible Target Multiple
|
||||
classification (`specs/TargetRevenueFrameworkCore.md` §1.4), not an
|
||||
arbitrary pick. Document why each candidate was chosen and what was
|
||||
passed over.
|
||||
|
||||
## Draft pilot Phase Manifests (non-binding worked examples)
|
||||
|
||||
```task
|
||||
id: TREV-WP-0008-T03
|
||||
status: todo
|
||||
priority: high
|
||||
```
|
||||
|
||||
Using T02's candidates, draft one Phase Manifest per product line
|
||||
following `specs/PhaseManifestSpecification.md` and
|
||||
`schemas/phase_manifest.schema.json` exactly — structurally valid,
|
||||
conformance-tested the same way `examples/phase-001/` is, but explicitly
|
||||
marked **draft / not yet declared** (no real Commercial Use restriction
|
||||
takes effect from these). Choose an applicable Monetization Extension per
|
||||
Phase from `workplans/TREV-WP-0007-degeneration-policy-and-canonical-profiles.md`
|
||||
T03's catalog.
|
||||
|
||||
## Contributor rights instrument (CLA)
|
||||
|
||||
```task
|
||||
id: TREV-WP-0008-T04
|
||||
status: todo
|
||||
priority: medium
|
||||
```
|
||||
|
||||
`CONTRIBUTING.md` currently blocks external contributions into any
|
||||
governed Milestone Release until a contributor-rights instrument exists
|
||||
(per `history/260729-TRSL-ContributorRights-Research.md`). If any pilot
|
||||
candidate from T02 has, or expects, external contributors before its
|
||||
Conversion Event, this is now practically blocking, not theoretical.
|
||||
Produce `specs/TRSL-ContributorLicenseAgreement-Draft.md`: a CLA scoped
|
||||
narrowly to the current Phase's TRSL terms plus its already-declared
|
||||
Future License, per the T04 research's recommendation. Same preliminary-
|
||||
candidate treatment as the License/CUA V1C1 documents (status banner,
|
||||
Appendix A-style candidate notes) — this is a new legal document, not
|
||||
exempt from that pattern.
|
||||
|
||||
## Go-live gate (human decision)
|
||||
|
||||
```task
|
||||
id: TREV-WP-0008-T05
|
||||
status: todo
|
||||
priority: high
|
||||
human_accept_required: true
|
||||
```
|
||||
|
||||
**Do not mark this task done to authorize real Phase declarations.** It
|
||||
exists to make the go-live decision a single, explicit, recorded moment
|
||||
rather than something that happens by accretion once enough pilot
|
||||
infrastructure exists. Before acceptance, confirm:
|
||||
|
||||
- `workplans/TREV-WP-0004-global-jurisdiction-research.md` T10 and
|
||||
`workplans/TREV-WP-0005-enforcement-network-research.md` T10 syntheses
|
||||
are complete, or their absence is an explicitly accepted risk;
|
||||
- specialist legal review of `specs/TargetRevenueSourceLicense-V1C1.md`
|
||||
and `specs/TargetRevenueCommercialUseAgreement-V1C1.md` (condition 1 in
|
||||
each document's status banner) has occurred, or is explicitly waived for
|
||||
a defined pilot scope;
|
||||
- T01's Licensor-identity question is resolved for whichever product
|
||||
line goes first;
|
||||
- `workplans/TREV-WP-0006-trust-service-implementation.md` has a working
|
||||
hosted Trust Service, or an explicit interim manual/git-based ledger
|
||||
process is accepted for the pilot instead.
|
||||
|
||||
Once accepted, this task's Result should name which specific repo and
|
||||
Phase go live first — "governance and rollout infrastructure exists" is
|
||||
not the same event as "a real Phase is declared," and this workplan should
|
||||
not blur that line even after everything above is ready.
|
||||
Loading…
Add table
Add a link
Reference in a new issue