Repository navigation
Immutable
release. Only release title and notes can be modified.
0.2.9 (2026-09-28)
Governance impact
Phase: ▣ P1 — unchanged
Items: 1 completed · 1 advanced · 12 introduced · 3 superseded
Completed · 1
| GV | Proposition |
|---|---|
| GV18 ◇ → ✓ | Allow versioned materializations to follow their governing source change in the immediately subsequent chore(materialize) commit; the final pushed or reviewed state must contain canonical materializations. |
Advanced · 1
| GV | Proposition |
|---|---|
| GV84 ◇ ↑ | Make observed invariant regressions counterexample-closing: once a contradiction to a governed or relied-upon invariant is recorded as an observed regression, its repair is incomplete until the counterexample is preserved as governed evidence, the missing or incorrectly scoped assurance boundary is corrected or overstated governance superseded, and candidate validation rejects recurrence before the affected workflow may succeed. |
Introduced · 12
| GV | Proposition |
|---|---|
| + GV111 ✓ | Replace the mechanically derived README Current/Next status of GV94 with a governed project-direction review while preserving roadmap structural validity: Current is a bounded human-facing summary anchored by typed coverage of the exact governed project and roadmap state; Next is a bounded human-facing summary of the selected gap between Purpose and Current; every relevant source subject must receive an explicit typed disposition, source changes invalidate review freshness, and the compiler verifies bounds, provenance, coverage, references, and vigilance freshness while the agent supplies semantic judgment and the human authorizes that judgment through the pull request. |
| + GV112 ✓ | Require consolidation closure for every declared session, handoff, recovery corpus, or other project-knowledge snapshot before semantic roadmap evolution: bind the corpus to immutable provenance and require every declared observation to receive exactly one explicit disposition as represented by governed state, superseded by an identified decision, rejected with rationale, or irrelevant with rationale; any undisposed observation keeps project direction stale and blocks semantic roadmap evolution, without claiming that the compiler can prove completeness of unobservable model memory or natural-language extraction. |
| + GV114 ◇ | Generalize administrative bootstrap across independent external providers while preserving one human-facing convergent setup: model one human administrative authority with explicit irreducible provider grants only where one provider cannot derive another provider credential; each bootstrap grant may enter only the main-only admin-materialization boundary, and Admin Materialize / setup must deterministically create, restrict, populate, and read-back verify the least-privileged target capability boundary for that provider. Provider grant fields may be packaged as one opaque secret when they jointly represent one authorization; target jobs receive only their own provider grant and never GOVENV_ADMIN_TOKEN or unrelated grants. Provider credentials create no semantic authority, and provider identity must be read back when the provider exposes a sound verification boundary. |
| + GV115 ◇ | Simplify developer-journal authorization into the existing pull-request lifecycle: every ordinary candidate pull request must include its own journal post text and square image bound to the exact candidate delta and current project direction, with typed coverage/disposition for every relevant change; human merge of that same pull request is the sole editorial authorization, after which only the exact reviewed artifacts may be published automatically to X without a second approval pull request or environment approval. Release Please pull requests substitute a release-journal preview for the ordinary PR post: each major or minor release preview must derive from the exact frozen typed ReleaseDocument, approval/merge of that Release Please pull request authorizes the exact release post, and publication occurs only after the corresponding release boundary; patch releases may omit a release post unless another rule requires one. Publication must be idempotent through the dedicated social capability boundary and retain revision-addressable read-back evidence of the resulting X post. |
| + GV116 ◇ | Migrate governance lifecycle, roadmap status, snapshots, and release deltas to append-only constitutional history: give formal Propositions identity independent from GovernanceId, treat the GovernanceId description as the human contract rather than formal truth, establish Obligations only through Proposition evidence, represent declaration/establishment/abandonment/disposition/supersession as validated history events, require atomic supersession coverage of outgoing responsibility, derive governance lifecycle and glyphs from that history rather than stored ItemState, preserve history-prefix snapshots, and derive constitutional release deltas from introduced governance, establishments, dispositions, supersessions, and phase progress while keeping activity-only advancement outside constitutional delta. |
| + GV117 ◇ | Classify dependency and environment authority according to GV101: keep reuse preference, ecosystem investigation, and contributor dependency-selection guidance in Protocol, but move repository-validity properties into Governance when they determine canonical project state, including the target absence of versioned devenv.yaml, governed materialization ownership of devenv.nix, transient non-authoritative devenv.lock state, and the prohibition on competing package-manager dependency authority; materialization and runtime backends must project those governed decisions without re-owning them. |
| + GV119 ✓ | Keep human learning coupled to conceptual project evolution: represent revision-bound learning requirements, human-produced challenge/response evidence, and outstanding learning debt without claiming to prove a principal's mental state; pull-request learning is a soft gate that may be bypassed only explicitly for urgent corrective work while preserving the resulting debt, feature and concept-expanding refactor work is blocked while debt remains, patch releases may carry known debt, and major or minor releases require zero outstanding learning debt. Expose status, catch-up, and review entrypoints from the governed developer environment. |
| + GV122 ✓ | Enforce GV119 at the exact pull-request candidate boundary: every substantive candidate must carry a fresh explicit learning assessment whose classification and rationale remain Protocol judgment, while Governance checks the recorded impact, requirements, human-produced evidence, outstanding debt, and any urgent-corrective bypass; concept-expanding feature/refactor candidates may merge only after their requirements are evidenced and all learning debt is closed, urgent corrective candidates may merge with unresolved requirements only when the same requirements are preserved as debt, and direct pull-request Test CI must apply this gate before ordinary candidate validation without re-owning its semantics. |
| + GV123 ✓ | Make GV122 reachable by a principal with no prospective Govenv learning history: define a governed bootstrap baseline pinned to the pre-GV122 project frontier that reconstructs the minimum causal learning path needed to review current effective semantics from zero; treat baseline selection and pedagogy as explicit Protocol judgment; derive outstanding learning debt from bootstrap requirements plus carried bypass debt minus human-produced evidence; expose bootstrap, catch-up, and human answer capture in the governed shell; preserve exact challenge/response evidence in a dedicated governed authority; allow an evidence-only candidate only when no other substantive source changes and the governed debt count strictly decreases; and require bootstrap debt to participate in the same feature/refactor and major/minor gates rather than creating a parallel or weaker learning authority. |
| + GV118 ◇ | Make repository-collaboration tooling an explicit governed runtime capability: the active shell must provide the project-selected provider CLI needed for candidate publication, beginning with GitHub pull-request authoring through gh in the devenv backend and later through govenv shell; agents must be able to discover and use that capability from Protocol without depending on a ChatGPT connector, IDE integration, or other out-of-band tool, while authentication remains an external runtime concern and collaboration tooling creates no semantic or authorization authority beyond the governed candidate and explicit human merge boundaries. |
| + GV120 ◇ | Define a canonical, versioned, language-neutral Governance IR as the semantic boundary between Govenv's Agda reference formalization and Govenv applications: compile governed identities, obligations, transitions, capabilities, authorization, evidence/certificates, and environment/runtime requirements into the IR with semantic-preservation assurance; language-specific provers, checkers, and adapters may validate certificates or reconstruct local proofs from that IR but must not independently redefine governance semantics. |
| + GV121 ◇ | Provide Agda formatting and linting as an external Govenv application rather than core semantic authority: prefer adopting a mature ecosystem formatter/linter when one becomes available; otherwise, once Govenv is sufficiently mature, allow a separately distributed formatter/linter to be developed using Govenv itself, with treefmt-compatible formatting and Protocol-style diagnostics while preserving the distinction between formatting/advice and constitutional validity. |
Superseded · 3
GV113 ↪ GV115
- Govern the developer journal as an approved projection of project evolution: every semantic Next change requires a direction post bound to the exact project-direction delta, and every major or minor release requires a release post bound to the exact frozen typed ReleaseDocument. Each draft must stay within the target platform limit, carry typed coverage/disposition for every relevant source change, use the canonical Govenv logo and square journal-image brief, be reviewed in the authorizing pull request or release candidate, and only the exact approved text/image may be published after authorization; publication credentials remain external secrets and successful publication is read back into revision-addressable evidence.
+ Simplify developer-journal authorization into the existing pull-request lifecycle: every ordinary candidate pull request must include its own journal post text and square image bound to the exact candidate delta and current project direction, with typed coverage/disposition for every relevant change; human merge of that same pull request is the sole editorial authorization, after which only the exact reviewed artifacts may be published automatically to X without a second approval pull request or environment approval. Release Please pull requests substitute a release-journal preview for the ordinary PR post: each major or minor release preview must derive from the exact frozen typed ReleaseDocument, approval/merge of that Release Please pull request authorizes the exact release post, and publication occurs only after the corresponding release boundary; patch releases may omit a release post unless another rule requires one. Publication must be idempotent through the dedicated social capability boundary and retain revision-addressable read-back evidence of the resulting X post.GV108 ↪ GV114
- Separate administrative bootstrap from authorized materialization around exactly one human-supplied administrative root, `GOVENV_ADMIN_TOKEN`: keep `Admin Materialize` as the single manually invoked setup/recovery/rotation boundary, limited to establishing, reconciling, and rotating subordinate authority and capability state; derive all subordinate credentials and boundaries without any additional manually supplied credential, and rotate governed subordinate credentials on rerun. Ordinary project state must not be an Admin Materialize setup step. Automatically reconcile every deterministic non-bootstrap materialization of an `AuthorizedRevision`, including versioned artifacts and GitHub repository description, website, and topics, with target-specific read-back verification. Automatic GitHub repository administration may consume `GOVENV_ADMIN_TOKEN` only inside the main-only administrative environment when GitHub exposes no narrower credential derivable without a second human bootstrap; candidate, agent, release, Pages, and repository Git-materializer paths must never receive it.
+ Generalize administrative bootstrap across independent external providers while preserving one human-facing convergent setup: model one human administrative authority with explicit irreducible provider grants only where one provider cannot derive another provider credential; each bootstrap grant may enter only the main-only `admin-materialization` boundary, and `Admin Materialize / setup` must deterministically create, restrict, populate, and read-back verify the least-privileged target capability boundary for that provider. Provider grant fields may be packaged as one opaque secret when they jointly represent one authorization; target jobs receive only their own provider grant and never `GOVENV_ADMIN_TOKEN` or unrelated grants. Provider credentials create no semantic authority, and provider identity must be read back when the provider exposes a sound verification boundary.GV94 ↪ GV111
- Make roadmap current state derived and self-consistent: while governance work remains, the active phase must contain non-terminal governance work, finished phases must remain terminal, and a complete roadmap may contain no non-terminal work. Every `Current` projection, including README status and next-work information, must be derived from typed roadmap state and may contain no independently maintained progress summary.
+ Replace the mechanically derived README Current/Next status of GV94 with a governed project-direction review while preserving roadmap structural validity: Current is a bounded human-facing summary anchored by typed coverage of the exact governed project and roadmap state; Next is a bounded human-facing summary of the selected gap between Purpose and Current; every relevant source subject must receive an explicit typed disposition, source changes invalidate review freshness, and the compiler verifies bounds, provenance, coverage, references, and vigilance freshness while the agent supplies semantic judgment and the human authorizes that judgment through the pull request.Derived from immutable typed roadmap snapshots and governed Refs: GV… commit metadata. SemVer remains independent. 79c0803..0045866.
Bug Fixes
- ci: validate transient candidate materializations (cfd24b6)
- consolidation: normalize recovery provenance (4a3ffea)
- protocol: require evidence for vigilance reviews (bbdc00c)
- constitution: prevent completed phase reopening (3c9c7d5)
- learning: make candidate gate reachable from zero (0045866)
Governance
- direction: establish review and journal protocol (badf7ea)
- direction: refine journal authorization and provider grants (cee3af0)
- direction: establish compiler-checked direction review (08da4e6)
- consolidation: close recovered project context (3622c38)
- constitution: establish append-only history kernel (ec78c35)
- constitution: derive lifecycle from history (91fe283)
- roadmap: project lifecycle from constitution (efc39e5)
- learning: couple learning debt to delivery (c9837df)
- runtime: govern repository collaboration capability (464091b)
- runtime: add GitHub auth onboarding hook (fd1d2d0)
- constitution: allow late formal propositions (a41faa5)
- roadmap: add language-neutral application phase (5ca5af5)
- constitution: add one-shot genesis boundary (6f88389)
- constitution: add history-prefix snapshots (7ccf5e0)
- constitution: derive phase progress from history (a9870a9)
- release: derive constitutional history delta (40f0fd1)
- materialization: define constitutional snapshot v3 (78f0a5f)
- constitution: add authorization-bound activation harness (3b592b6)