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>
3.4 KiB
| id | type | title | domain | repo | status | owner | topic_slug | created | updated |
|---|---|---|---|---|---|---|---|---|---|
| TREV-WP-0007 | workplan | Degeneration policy research and canonical monetization profiles | infotech | target-revenue | active | claude | infotech | 2026-07-29 | 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
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)
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
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)
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.