133 lines
5 KiB
Markdown
133 lines
5 KiB
Markdown
|
---
|
|||
|
|
id: TREV-WP-0015
|
|||
|
|
type: workplan
|
|||
|
|
title: "Implement Phase provenance, spec-file, and ledger UI changes"
|
|||
|
|
domain: infotech
|
|||
|
|
repo: target-revenue
|
|||
|
|
status: active
|
|||
|
|
owner: claude
|
|||
|
|
topic_slug: infotech
|
|||
|
|
created: "2026-08-03"
|
|||
|
|
updated: "2026-08-03"
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# Implement Phase provenance, spec-file, and ledger UI changes
|
|||
|
|
|
|||
|
|
Implements `specs/PhaseProvenanceSpecAddendum.md`, accepted 2026-08-03,
|
|||
|
|
which itself synthesizes the decisions from
|
|||
|
|
`workplans/TREV-WP-0012-phase-provenance-and-policy-modeling.md` T02–T04.
|
|||
|
|
Task numbering below matches the addendum's §6 suggested breakdown
|
|||
|
|
1:1 — each task cites its addendum section as the authoritative source of
|
|||
|
|
what to build, rather than re-deriving field shapes or rationale here.
|
|||
|
|
|
|||
|
|
```task
|
|||
|
|
id: TREV-WP-0015-T01
|
|||
|
|
status: todo
|
|||
|
|
priority: high
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**Schema change** (addendum §1): add `repo_hub`, `repo_hub_uri`,
|
|||
|
|
`repo_id`, `repo_name` as required properties of
|
|||
|
|
`phase.milestone_release`, and `phase.base_phase_id` as an optional
|
|||
|
|
property of `phase`, to `schemas/phase_manifest.schema.json`. Update
|
|||
|
|
`validation.py` if the new pattern/format constraints need anything
|
|||
|
|
beyond what JSON Schema's own `pattern`/`format` keywords already
|
|||
|
|
enforce (they shouldn't). Add offline tests: a manifest missing any of
|
|||
|
|
the four new required fields is rejected; one with `base_phase_id`
|
|||
|
|
absent validates (first Phase); one with it present and correctly
|
|||
|
|
patterned validates (successive Phase).
|
|||
|
|
|
|||
|
|
```task
|
|||
|
|
id: TREV-WP-0015-T02
|
|||
|
|
status: todo
|
|||
|
|
priority: high
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**Spec-file extraction** (addendum §2): create `specs/policies/
|
|||
|
|
linear-longstop-v0.md` (extracted from `specs/
|
|||
|
|
OpenQuestions-WorkingDefaults.md` Q7's prose, with `policy_id`/`title`
|
|||
|
|
frontmatter); create the six `specs/profiles/*.md` files (extracted from
|
|||
|
|
`specs/CanonicalMonetizationProfiles.md` §1–§6, with `extension_id`/
|
|||
|
|
`title` frontmatter), leaving §7 (cross-profile summary) and §8
|
|||
|
|
(non-goals) in place as the overview document. Add `calculator_id`/
|
|||
|
|
`revision`/`title` frontmatter to `specs/
|
|||
|
|
DevelopmentEffortCalculatorConcept.md` (no move). Update
|
|||
|
|
`OpenQuestions-WorkingDefaults.md` Q7 to point at the new file rather
|
|||
|
|
than contain the policy's content directly.
|
|||
|
|
|
|||
|
|
```task
|
|||
|
|
id: TREV-WP-0015-T03
|
|||
|
|
status: todo
|
|||
|
|
priority: medium
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**Control Plane reference-rendering routes** (addendum §2): add
|
|||
|
|
`GET /reference/policies/{slug}` and `GET /reference/profiles/{slug}` to
|
|||
|
|
`service/control_plane_app.py`, rendering the corresponding
|
|||
|
|
`specs/policies/`/`specs/profiles/` markdown file to HTML server-side at
|
|||
|
|
request time (a small Python markdown library — confirm one is already
|
|||
|
|
an acceptable addition to the `service` extras in `pyproject.toml`, or
|
|||
|
|
add it). Read-only, no edit capability. Link to these routes from
|
|||
|
|
wherever a policy id or extension id already appears in
|
|||
|
|
`phase_detail.html`/`phase_new.html`.
|
|||
|
|
|
|||
|
|
```task
|
|||
|
|
id: TREV-WP-0015-T04
|
|||
|
|
status: todo
|
|||
|
|
priority: medium
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**Ledger UI change** (addendum §3): drop the `ledger` input from
|
|||
|
|
`phase_new.html`; have the registration route auto-compute
|
|||
|
|
`phase.ledger` as the canonical `/phases/{phase_id}/ledger` reference
|
|||
|
|
before validation/persistence. Add a small "ledger reference"
|
|||
|
|
link/disclosure to `phase_detail.html` showing the raw reference plus a
|
|||
|
|
live-data link when it resolves to this same instance. The existing
|
|||
|
|
Ledger entries table is untouched.
|
|||
|
|
|
|||
|
|
```task
|
|||
|
|
id: TREV-WP-0015-T05
|
|||
|
|
status: todo
|
|||
|
|
priority: high
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**`forgejo_hubs` migration** (addendum §4): new migration
|
|||
|
|
`migrations/0007_forgejo_hubs.sql`, table `forgejo_hubs (hub_slug
|
|||
|
|
PRIMARY KEY, service_uri, first_seen_at, updated_at)`, auto-populated on
|
|||
|
|
first sight of a `repo_hub` during Phase registration (mirroring
|
|||
|
|
`ensure_licensor_identity`'s auto-create-on-first-INSERT trigger
|
|||
|
|
pattern in `migrations/0005_licensor_credentials.sql`). Decide during
|
|||
|
|
implementation (not a T02-style human gate, per the addendum) whether
|
|||
|
|
correcting a hub's URI after the fact is a `SECURITY DEFINER` governance
|
|||
|
|
action or a plain `UPDATE`, and document whichever is chosen.
|
|||
|
|
|
|||
|
|
```task
|
|||
|
|
id: TREV-WP-0015-T06
|
|||
|
|
status: todo
|
|||
|
|
priority: medium
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**Backfill the three example manifests** (addendum §5):
|
|||
|
|
`examples/pilot-candidates/{net-kingdom-local-identity,
|
|||
|
|
railiance-vergabe-teilnahme, info-tech-canon-service-surface}/manifest.json`
|
|||
|
|
each get `repo_hub`/`repo_hub_uri`/`repo_id`/`repo_name` from their real
|
|||
|
|
Forgejo data (`GET /api/v1/repos/{owner}/{repo}`, same call already
|
|||
|
|
confirmed working for `target-revenue` itself during WP-0012-T02), no
|
|||
|
|
`base_phase_id` (all three are first Phases), and `ledger` set to match
|
|||
|
|
what the Control Plane would now auto-compute.
|
|||
|
|
|
|||
|
|
```task
|
|||
|
|
id: TREV-WP-0015-T07
|
|||
|
|
status: todo
|
|||
|
|
priority: high
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**Tests, docs, and closeout**: offline schema/validation tests (T01),
|
|||
|
|
Docker-gated `TestClient` tests for T03's new routes and T04/T05's
|
|||
|
|
changes (extending `tests/test_control_plane_app.py`), a rendering smoke
|
|||
|
|
test that each `specs/policies/`/`specs/profiles/` file actually renders
|
|||
|
|
without error. Update `README.md`'s WP-0015 row and this workplan's
|
|||
|
|
Result sections; run the full offline + Docker-gated suite; fence-count
|
|||
|
|
check before committing any workplan edit, per this project's standing
|
|||
|
|
practice.
|