chore: mark v0.33 release checklist complete#46
Conversation
- tools/autoflow/: state machine, 6 readers, reporter, CLI - 5 fixtures (released/active/planned/drifted/invalid) - 35 unit + integration tests - deno task autoflow:report (advisory only, no CI gate) - docs/next/v0.34.0/ execution package
- Bump all 19 packages to 0.34.0 - CHANGELOG v0.34.0 entry - docs/release/v0.34.0.md release note - STATUS.md: v0.34 current, v0.33 historical - ROADMAP.md: v0.34 Current, v0.35 Next - SOP v0.34.0 tasks completed - workflow:check activeVersion → v0.34.0 - deno task autoflow:report → reports implemented state
Deploying openelement with
|
| Latest commit: |
2e07dcd
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://274ad4d6.lessjs.pages.dev |
| Branch Preview URL: | https://dev.lessjs.pages.dev |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5c671c51ee
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const mismatched = packages.filter((p) => { | ||
| // Normalize: strip leading 'v' from versions for comparison | ||
| const pkgVer = p.version.replace(/^v/, ''); | ||
| const expVer = expectedVersion.replace(/^v/, ''); | ||
| return pkgVer !== expVer; |
There was a problem hiding this comment.
Include internal JSR ranges in package alignment
In the current v0.34 manifests, packages such as packages/app/deno.json still import internal packages with jsr:@openelement/*@^0.33.0, but this AutoFlow reader only compares each package's own version field. Because ^0.33.0 does not include 0.34.0 for 0.x semver, deno task autoflow:report will report Package Graph as ok and can put the workflow in implemented even when the existing package graph gate would reject the release-line drift; parse imports here too so the sidecar catches the same internal range mismatches.
Useful? React with 👍 / 👎.
| packagesAligned: packageGraph.allAligned, | ||
| tagExists: false, // v0.34 doesn't check git | ||
| releaseNoteExists: false, // v0.34 doesn't check git | ||
| statusDeclaresCurrent: status.currentVersion === version, |
There was a problem hiding this comment.
Compare status-current evidence to an independent source
In the CLI path, version is assigned from status.currentVersion just above, so this evidence is true for every parseable STATUS.md. When a NextVersion package exists but the workflow is still in the next phase, the report skips next and promotes it to active, which changes the allowed actions; compare against the SOP/roadmap status or the parsed NextVersion path instead of the same value.
Useful? React with 👍 / 👎.
| createCell( | ||
| 'release', | ||
| 'ok', | ||
| 'Release check: see deno task publish:dry-run', | ||
| 'docs/release/', |
There was a problem hiding this comment.
Stop marking release evidence ok unconditionally
For implemented-but-not-released versions, or for any version missing docs/release/<version>.md, this still reports the Release cell as ok and produces no blocker because it never reads the release evidence. That makes the sidecar summary usable as PR evidence even when the release note/tag evidence is absent; derive this status from the actual release-note/tag checks or mark it warning/missing until verified.
Useful? React with 👍 / 👎.
| ), | ||
| createCell( | ||
| 'sop', | ||
| sop.sopFileFound ? sop.completedTasks === sop.totalTasks ? 'ok' : 'warning' : 'missing', |
There was a problem hiding this comment.
Treat taskless SOPs as missing evidence
If docs/sop/<version>/README.md exists but contains no checklist items, this ternary marks the SOP cell ok because 0 === 0. For a malformed or placeholder SOP, the report would show no SOP blocker even though there are no tasks proving completion; require totalTasks > 0 before reporting ok, or mark it warning/missing.
Useful? React with 👍 / 👎.
| if (evidence.hasDrift) return 'drifted'; | ||
|
|
||
| if (evidence.releaseNoteExists && evidence.tagExists) return 'released'; | ||
| if (evidence.sopTasksComplete && evidence.packagesAligned) return 'implemented'; |
There was a problem hiding this comment.
Require NextVersion evidence before implemented
When the active docs/next/<version>/ package is missing or incomplete but SOP tasks are complete and package versions align, determineState returns implemented here. That skips the required next/active evidence and emits implemented allowed actions while the NextVersion cell is missing; gate this state on nextVersionComplete and current-status evidence too, or treat the contradiction as drift.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2e07dcd49c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "@openelement/core": "jsr:@openelement/core@^0.34.0", | ||
| "@openelement/core/logger": "jsr:@openelement/core@^0.34.0/logger", | ||
| "@openelement/adapter-vite": "jsr:@openelement/adapter-vite@^0.34.0", | ||
| "@openelement/content": "jsr:@openelement/content@^0.34.0", | ||
| "@openelement/i18n": "jsr:@openelement/i18n@^0.34.0", |
There was a problem hiding this comment.
Commit the regenerated lockfile with the bump
This package and the rest of the workspace now depend on @openelement/*@^0.34.0, but the same commit leaves deno.lock with workspace dependencies pinned to jsr:@openelement/*@0.33 (for example the app entry still lists adapter-vite/content/core/i18n at 0.33). Because Deno discovers and uses the root lockfile from deno.json and updates it when dependency requirements change, clean dev/CI runs for this release line will either rewrite the committed lockfile or fail under a frozen-lock invocation; include the regenerated lockfile with the package-line bump.
Useful? React with 👍 / 👎.
| - [ ] Create `tools/autoflow/` directory structure. | ||
| - [ ] Create `tools/autoflow/mod.ts` CLI entry. | ||
| - [ ] Create `tools/autoflow/__tests__/` directory. | ||
| - [ ] Add `deno task autoflow:report` to `deno.json`. | ||
| - [ ] Verify `deno task autoflow:report` runs without error (stub). |
There was a problem hiding this comment.
Mark NextVersion tasks before release
The commit promotes v0.34.0 to IMPLEMENTED AND RELEASED in STATUS.md, but the v0.34 NextVersion package still has every implementation task and release-checklist item unchecked. In the released/current state this leaves the workflow evidence self-contradictory for maintainers and AutoFlow consumers: the status/release docs say the line is closed while the execution package says none of the scaffold, state-machine, reader, reporter, fixture, gate, or release work is complete.
Useful? React with 👍 / 👎.
| status: string; | ||
| } | ||
|
|
||
| const VERSION_ROW_RE = /^\|\s*(v[\d.]+)\s*\|\s*(.+?)\s*\|\s*(\S+)\s*\|/gm; |
There was a problem hiding this comment.
Parse the roadmap status column, not the purpose column
The actual roadmap table has four columns (Version | Theme | Purpose | Status), but this regex stops after the third cell and stores the Purpose text as status. For the current repo this means the v0.34.0 row is parsed with status Add... instead of Current, so readRoadmap() reports currentVersion as empty and cannot catch STATUS/ROADMAP drift on the same format it is meant to read.
Useful? React with 👍 / 👎.
|
|
||
| const adrs: AdrInfo[] = []; | ||
| for (const entry of entries) { | ||
| if (!entry.isFile || !entry.name.startsWith('ADR-') || !entry.name.endsWith('.md')) continue; |
There was a problem hiding this comment.
Include numeric ADR filenames in the ADR reader
This filter only accepts files named ADR-*.md, but the repository still contains 21 active ADR files named like 0025-renderer-protocol.md through 0041-... and 0057-... that are listed in docs/adr/README.md. In this repo layout the AutoFlow ADR cell silently undercounts and skips the status/title evidence for those decisions, so governance drift in the older ADR set will never appear in the report.
Useful? React with 👍 / 👎.
| { | ||
| "name": "@openelement/ui", | ||
| "version": "0.33.0", | ||
| "version": "0.34.0", |
There was a problem hiding this comment.
Keep exported UI metadata on the bumped version
This publishes @openelement/ui as 0.34.0, but the exported package manifest in packages/ui/src/manifest.ts still says version: '0.33.0'. Consumers that read the manifest exported from @openelement/ui to derive component/package metadata will record the newly published 0.34 package as 0.33, which makes generated manifests and registry/hub records stale even though the package's deno.json was bumped.
Useful? React with 👍 / 👎.
| export interface Report { | ||
| version: string; | ||
| workflowState: WorkflowState; | ||
| cells: Cell[]; | ||
| blockers: Blocker[]; | ||
| allowedActions: string[]; | ||
| } |
There was a problem hiding this comment.
Include the promised evidence object in JSON reports
The v0.34 SOP/NextVersion docs require the sidecar JSON to include structured evidence, and downstream PR evidence is supposed to use this report as the machine-readable ledger. The exported Report shape and reportJson() output only contain cells/blockers/actions, so any consumer that needs to distinguish raw facts like parsed status version, SOP task counts, NextVersion completeness, package alignment, or release/tag evidence has to re-run the readers instead of trusting the JSON report.
Useful? React with 👍 / 👎.
Pull Request
Read first:
docs/governance/PROJECT_WORKFLOW.mdTarget
What Changed
Evidence
deno task autoflow:checkdeno task workflow:checkdeno task arch:checkdeno task graph:checkdeno task docs:check-currentdeno task docs:check-strategydeno task fmt:checkdeno task lintdeno task typecheckdeno task testdeno task buildRelease Impact