|
Pokered Save Editor 2
Pokemon Red & Blue save file editor - Qt 6 C++/QML
|
The standing check-for-updates flow ran again (scheduled task). Refreshed the git-ignored hub mirror — hub dev force-pushed again (42b6ea4 → 6777a73, reconciled with fetch + reset --hard on the mirror only), hub VERSION 0.9.2 → 0.9.4. Those two commits are hub-side housekeeping: 0.9.3 folded the verification-floor clarification + .last-seen.yml reports_through marker scheme into the standards, and 0.9.4 reconciled/blogged this project's express-auth adoption. Both reflect work already adopted here in today's two earlier passes — nothing new to adopt.
Cross-checks all agreed: the hub's .last-seen.yml records this node at dev 3ff32c6 with both of today's reports digested; the adopted cross-project-sync.md, git-workflow.md, and versioning.md carry the current ledger-read, verification floor, force-push fallback, and ## Verify sections; authorizations.yml has only the standing express-authorization-rollout entry already honored. VERSION unchanged at 0.14.2-alpha. Check-only — nothing applied. Report: notes/fairyfox-reports/2026-06-26-check-for-updates.md.
Later the same day, the standing check-for-updates flow ran (scheduled task) and found the hub had advanced 0.8.1 → 0.9.2 since the morning's adoption. The headline change is a new express-authorization mechanism: a hub authorizations.yml ledger whose active entries cover specific standards, letting a node adopt a covered change without the check-and-report pause — skipping only that pause, with every other safety step (copy-not-clobber, divergence re-prompt, process report, reviewable commit) still running. Companion edits added the reset --hard mirror fallback for the routinely force-pushed hub dev, a CI-vs-by-hand tagging subsection in git-workflow.md (already covered here), and made hub_version the durable "last adopted" anchor in process reports.
The scheduled run itself did not apply anything (unattended + the change is a trust-model shift); it reported and waited. On Twilight's "please proceed" it became an adopt in the same session, so per the new process-reports rule it's one combined adopting-updates report (notes/fairyfox-reports/2026-06-26-adopting-updates-express-auth.md). Adopted into CLAUDE.md (mesh block: the pre-authorized-change exception + reworded guardrails) and notes/reference/cross-project-sync.md (the mirror fallback + the ledger-read paragraph and anti-recursion bullet). Notes/docs-only — no VERSION bump, no changelog entry, no main release. Commit 593859b.
Twilight then set a standing constraint: safeties, checks, tests, and compliance must be run regularly and comprehensively at every level throughout — especially around any automated or express-authorized applying. Pre-authorization skips only the confirmation pause, never the verification; if full verification (reconcile, build/tests, compliance ## Verify, staying within all project constraints) can't be completed, don't auto-apply — fall back to check-report-wait. Baked into the CLAUDE.md mesh block and the process report.
Ran the fairyfox check-for-updates flow, then (on Twilight's go-ahead) the adopting-updates flow. The hub had advanced to dev 42263fe / VERSION 0.8.1 since the last adoption (docs-site theming, ~0.5–0.6.x), adding three things this repo didn't have: full git-flow, the process-reports standard, and the compliance / ## Verify enforcement layer. The hub's dev had been force-pushed, so the read-only clone was deleted + re-cloned per the runbook's fallback.
git-flow (full). Rewrote notes/reference/git-workflow.md from the old dev → main fast-forward model to git-flow: main advances only by --no-ff tagged-release merges, feature//release//hotfix/ support branches, PATCH releases go direct dev → main, MINOR/MAJOR through a release/X.Y.0 branch. Added a ## Verify section. Kept the project-specific bits (the Windows VERSION-checkout collision gotcha; the master→main rename was already done back on 2026-06-08, so that half of git-flow was a no-op here). Updated CLAUDE.md (git-workflow table row
One recorded divergence — CI owns the release tag. The hub runbook ends a release with a manual git tag, but this repo's release.yml already derives v<VERSION> and creates the tag itself (softprops) on the main push, and its version job skips the release if the tag already exists. Following the runbook literally would make every release silently no-op. So we diverge on purpose: the --no-ff merge to main is the release act and CI applies the tag — do not git tag by hand. Documented in git-workflow.md, versioning.md, and the release.yml header comment (comment-only; the pipeline is functionally unchanged → no CI risk).
process-reports. Stood up notes/fairyfox-reports/ (README + a new 2026-06-26-adopting-updates.md report) and wired it into _nav.dox. Every fairyfox system run here now ends with an honest report the hub reads to improve the standards.
compliance. Added ## Verify sections to git-workflow.md and versioning.md, and documented the compliance audit + process-reports model in cross-project-sync.md.
Recorded the adoption in the changelog. No VERSION bump — this is docs/standards/CI only (no app code changed), so per the versioning rule the number doesn't move; under the newly-adopted git-flow, main advances only at a real release, so this work rides to main with the next one rather than fast-forwarding on its own (committed + pushed on dev). Nothing in the reference clone was committed (git-ignored). The process report flags two runbook gaps back to the hub: (1) the manual-tag step should warn the CI-owns-tagging case, (2) nodes need a "last adopted hub version" marker so the next adoption has a bounded diff instead of reconstructing from a force-pushed hub log.
1.17.0 