From 9b9070be135461443b461b7a4f4cc22365e3e4d4 Mon Sep 17 00:00:00 2001 From: ProfessorPolymorphic <116023536+ProfessorPolymorphic@users.noreply.github.com> Date: Mon, 27 Jul 2026 06:00:59 -0700 Subject: [PATCH 1/2] Bump data-governance: `scoping` lands in the ProjectStatus vocabulary MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Closes the follow-up ADR 0001's 2026-07-24 amendment named and never did: the vendored iids-portfolio ProjectStatus vocabulary did not list `scoping`, while lib/portfolio.ts has used it since July and one project currently claims it. Nothing would have caught this. The governance drift workflow does not run on lib/portfolio.ts changes, so the typed union and the vendored registry can diverge in silence — which is the failure mode the catalog exists to prevent. Upstream ui-insight/data-governance#17 adds `scoping` at Display_Order 2 between idea and approved, corrects the Exploring rollup to include it, and sharpens `idea` (which read "no owner OR no sponsor" and would now overlap scoping — the verifier means neither). This bumps the submodule pointer and regenerates the typed catalog from it. Regenerated, not hand-edited, per Agent Rule 13. npm run build, npm run lint, and npm run verify:portfolio all pass (29 projects, 0 errors, 2 pre-existing stale-commit-date warnings). Co-Authored-By: Claude Opus 5 --- lib/governance/vocabularies.ts | 33 ++++++++++++++++++++------------- vendor/data-governance | 2 +- 2 files changed, 21 insertions(+), 14 deletions(-) diff --git a/lib/governance/vocabularies.ts b/lib/governance/vocabularies.ts index fef6b8c..715813e 100644 --- a/lib/governance/vocabularies.ts +++ b/lib/governance/vocabularies.ts @@ -572,76 +572,83 @@ export const vocabularyGroups: VocabularyGroup[] = [ "code": "idea", "label": "Idea", "displayOrder": 1, - "description": "Named with a unit-of-interest; not yet committed to build.", - "verificationRule": "No committed operationalOwner OR no committed iidsSponsor; repoUrl empty or repo has zero commits." + "description": "Named with a unit-of-interest; no owner or sponsor engaged yet.", + "verificationRule": "No committed operationalOwner AND no committed iidsSponsor (either one engaged makes it scoping); repoUrl empty or repo has zero commits." + }, + { + "code": "scoping", + "label": "Scoping", + "displayOrder": 2, + "description": "Named humans engaged; feasibility and shape being worked out before a formal go decision.", + "verificationRule": "A named operationalOwners[0] OR iidsSponsor is engaged (neither means it is still idea); no liveUrl; pilotCohort empty. No repo-cadence requirement — scoping produces framing and feasibility work, not necessarily commits." }, { "code": "approved", "label": "Approved", - "displayOrder": 2, + "displayOrder": 3, "description": "Committed to build with named owner and sponsor; not yet under active development.", "verificationRule": "operationalOwners[0] set AND iidsSponsor set AND non-empty description; no liveUrl; repo (if present) has <10 commits OR no commits in last 14 days." }, { "code": "building", "label": "Building", - "displayOrder": 3, + "displayOrder": 4, "description": "Active development. Code exists but not yet for real users.", "verificationRule": "repoUrl set; lastCommitDate within last 60 days; no liveUrl (or liveUrl flagged liveUrlIsStaging:true); pilotCohort empty." }, { "code": "prototype", "label": "Prototype", - "displayOrder": 4, + "displayOrder": 5, "description": "Demo-able but quiet — feature-complete or dormant.", "verificationRule": "pilotCohort empty; either lastCommitDate older than 30 days OR featureComplete:true." }, { "code": "piloting", "label": "Piloting", - "displayOrder": 5, + "displayOrder": 6, "description": "In use by a bounded, named cohort.", "verificationRule": "liveUrl set; pilotCohort populated with size > 0 and a bounded scope." }, { "code": "production", "label": "Production", - "displayOrder": 6, + "displayOrder": 7, "description": "In real institutional use beyond the pilot cohort.", "verificationRule": "Publicly-accessible artifact: liveUrl OR a public repoUrl (isPrivateRepo:false) for repo-as-artifact deliverables (infrastructure, scaffolds, appliances). productionScope and supportContact populated." }, { "code": "maintained", "label": "Maintained", - "displayOrder": 7, + "displayOrder": 8, "description": "In production but in maintenance-only mode.", "verificationRule": "Inherits production accessibility (liveUrl or public repo); no commits to main in last 90 days; no open feature issues — only bug-, security-, or chore-labeled." }, { "code": "paused", "label": "Paused", - "displayOrder": 8, + "displayOrder": 9, "description": "Deliberately on hold — not abandoned; expected to resume.", "verificationRule": "Deliberate hold, so no commit-cadence requirement; pilotCohort empty." }, { "code": "sunsetting", "label": "Sunsetting", - "displayOrder": 9, + "displayOrder": 10, "description": "Being wound down with a planned successor.", "verificationRule": "sunsetDate (ISO) set; replacedBy populated — successor project slug or the literal 'manual-process'." }, { "code": "archived", "label": "Archived", - "displayOrder": 10, + "displayOrder": 11, "description": "Stopped. Record kept for institutional memory.", "verificationRule": "liveUrl returns 404 / is null / domain dead, or (for repo-as-artifact) repoUrl is archived/deleted; service stopped." }, { "code": "tracked", "label": "Tracked", - "displayOrder": 11, + "displayOrder": 12, "description": "Externally-owned project IIDS observes but does not build.", "verificationRule": "trackingOnly:true; bypasses the operational ladder." } @@ -658,7 +665,7 @@ export const vocabularyGroups: VocabularyGroup[] = [ "label": "Exploring", "displayOrder": 1, "description": "Thinking about it / committed to build.", - "verificationRule": "Rolls up from ProjectStatus values: idea, approved." + "verificationRule": "Rolls up from ProjectStatus values: idea, scoping, approved." }, { "code": "building", diff --git a/vendor/data-governance b/vendor/data-governance index 74e1341..d3ce81b 160000 --- a/vendor/data-governance +++ b/vendor/data-governance @@ -1 +1 @@ -Subproject commit 74e134141d5a5aea229cde3beacbd7cdb94a2d58 +Subproject commit d3ce81b56ad33e1744f3b92dfdc246f47349a6d6 From b187679a98134af160feff3d4538337ead264ebc Mon Sep 17 00:00:00 2001 From: ProfessorPolymorphic <116023536+ProfessorPolymorphic@users.noreply.github.com> Date: Mon, 27 Jul 2026 06:04:33 -0700 Subject: [PATCH 2/2] Scope ADR 0005's status to what was actually decided MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The header read `Proposed` / `Deciders: Pending` three days after Phase 1 shipped, so the index was telling readers that a decision embodied in live tables, live code, and a public surface had not been made yet. The fix is not a flat flip to Accepted. This ADR does two different things: it designs a registry this repo owns and can build alone, and it proposes a division of institutional labour that binds other offices — TDX as the workflow system of record, a shared prioritization model, OIT's ownership of the approved-tools list. The first was decided and built. The second is still a proposal, and nothing in this repo can accept it on the working group's behalf. Marking the whole ADR Accepted would assert a ratification that hasn't happened, in the audit trail itself. So the status is split, with a dated amendment recording the split (append-only, per this directory's own lifecycle rules) and an inventory of what exists: Phase 1's five tables plus lib/utr.ts, lib/requests.ts, Migration 019's survey candidates, and /portfolio/pipeline are Accepted; the TDX boundary, prioritization model, and approved-tools ownership stay Proposed; Phases 2-4 are unbuilt, and the amendment names the specific tables and modules that don't exist so the gap is checkable rather than implied. Deciders now names Barrie Robison for the part that was decided, rather than "Pending". The format section of docs/adr/README.md gains a line permitting a scoped status for this case, since ADR 0005 is now the precedent — with the constraint that a header must never imply a ratification that hasn't happened. Co-Authored-By: Claude Opus 5 --- ...005-unified-technology-request-registry.md | 54 ++++++++++++++++++- docs/adr/README.md | 6 ++- 2 files changed, 57 insertions(+), 3 deletions(-) diff --git a/docs/adr/0005-unified-technology-request-registry.md b/docs/adr/0005-unified-technology-request-registry.md index 64b493e..3a61077 100644 --- a/docs/adr/0005-unified-technology-request-registry.md +++ b/docs/adr/0005-unified-technology-request-registry.md @@ -1,8 +1,8 @@ # ADR 0005 — Unified Technology Request: request registry & governance tracking -**Status:** Proposed — for discussion with the UTR working group (Hunter, Victoravich, Bartlett, Ewart, Robison) +**Status:** Accepted for the registry layer and Phase 1 (shipped 2026-07-24). The cross-institutional pieces — the TDX boundary, the prioritization model, and approved-tools ownership — remain **proposed**, pending the UTR working group (Hunter, Victoravich, Bartlett, Ewart, Robison). See the 2026-07-27 amendment. **Date:** 2026-07-23 -**Deciders:** Pending — Barrie Robison (IIDS) + UTR working group +**Deciders:** Barrie Robison (IIDS), for the registry design and Phase 1 as built. Working-group ratification outstanding for the pieces that bind other offices. **Related:** [ADR 0001](./0001-product-lifecycle-taxonomy.md) (lifecycle), [ADR 0004](./0004-clickup-ingestion-boundary.md) (ingestion pattern this extends), Migration 012 (enterprise-replacement facts), `UnifiedTechRequest/Unified Technology Request Process.pptx` (July 2026 draft), UTR meeting notes + email thread of 2026-07-20 → 2026-07-23 ## Context @@ -373,3 +373,53 @@ story with no public vs. internal distinction**. - This supersedes the "internal first" posture above **for the request queue**. Prioritization rounds (Phase 4) will make their own visibility call when they land. + +### 2026-07-27 — Status: Proposed → Accepted for Phase 1 + +**Context.** This ADR was written as a proposal to the UTR working group +and its header still said `Proposed` / `Deciders: Pending` three days +after Phase 1 shipped. A documentation audit flagged the mismatch: the +index in [`docs/adr/README.md`](./README.md) was telling readers that a +decision embodied in live tables, live code, and a public surface had not +been made yet. + +The confusion is real rather than clerical. This ADR does two different +things. It designs a registry **this repo owns and can build alone**, and +it proposes a division of labour that **binds other offices** — TDX as +the workflow system of record, a shared prioritization model, OIT's +ownership of the approved-tools list. The first was decided and built. +The second is still a proposal, and nothing here can accept it on the +working group's behalf. + +**Decision.** Split the status rather than flatten it. + +- **Accepted** — the registry layer and Phase 1 as built: `tech_requests`, + `tech_request_events`, `tech_request_links`, + `tech_request_project_links`, and `roi_claims` (Migration 018); + `lib/utr.ts` and `lib/requests.ts`; the backfill of ClickUp requests, + site submissions, and the GEO/Scrunch records; the survey candidates + registered by Migration 019; and `/portfolio/pipeline` as the single + all-origin queue (the Phase 2 line item pulled forward per the + 2026-07-24 amendment). Decided by the portfolio owner; these needed no + external dependency, which is exactly why Phase 1 was scoped that way. +- **Still proposed** — §1's assignment of workflow to TDX, §5's + `sync-tdx.ts` boundary, the prioritization model (open question 1), and + approved-tools ownership (open question 2). These describe how other + offices would work and are for the working group to ratify, amend, or + reject. +- **Not yet built** — Phases 2, 3, and 4. No `project_interest_pool`, + `governance_flags`, `project_gates`, or `prioritization_*` tables + exist; `lib/approved-tools.ts`, `/standards/approved-tools`, + `/internal/prioritization`, and `scripts/sync-tdx.ts` are all + unwritten. Phase 4's TDX sync remains blocked on API access. + +**Why not simply mark the whole thing Accepted.** It would assert that a +group which has not met on it signed off on a division of institutional +labour. The site's own standard is that every claim names a human and +holds up; an ADR header overclaiming ratification fails that standard in +the audit trail itself. + +**Follow-up.** When the working group does take this up, record the +outcome as a further amendment — including a rejection, if that is the +outcome. The header should stop hedging once there is something real to +point at. diff --git a/docs/adr/README.md b/docs/adr/README.md index d184842..143905b 100644 --- a/docs/adr/README.md +++ b/docs/adr/README.md @@ -33,6 +33,10 @@ By convention, follow the shape of [`0001-product-lifecycle-taxonomy.md`](./0001 # ADR NNNN — Short title **Status:** Proposed | Accepted | Superseded by [ADR NNNN](./NNNN-...) + (an ADR that decides some things this repo owns and proposes + others that bind another office may scope its status — see + ADR 0005 — but say which part is which, and never let a + header imply a ratification that hasn't happened) **Date:** YYYY-MM-DD **Deciders:** Names of the people who actually made the call **Supersedes:** (optional) Pointer to the ADR or pattern this replaces @@ -82,6 +86,6 @@ ADRs are **append-only**. To change a decision: | [0002](./0002-strategic-plan-alignment-explorer.md) | Strategic Plan Alignment Explorer | Accepted | 2026-05-03 | | [0003](./0003-strategic-plan-map-home.md) | Strategic-Plan Map Home + `/explore` Retirement | Accepted | 2026-05-05 | | [0004](./0004-clickup-ingestion-boundary.md) | ClickUp Ingestion Boundary | Accepted | 2026-07-10 | -| [0005](./0005-unified-technology-request-registry.md) | Unified Technology Request: Request Registry & Governance Tracking | Proposed | 2026-07-23 | +| [0005](./0005-unified-technology-request-registry.md) | Unified Technology Request: Request Registry & Governance Tracking | Accepted (Phase 1); cross-institutional pieces proposed | 2026-07-23 | | [0006](./0006-coordination-surface-split.md) | Split `/coordination` out of `/standards` | Accepted | 2026-07-25 | | [0007](./0007-site-assistant-tool-grounded-qa.md) | Site Assistant: Tool-Grounded Q&A with Strict Citation | Accepted | 2026-07-27 |