Conversation
…bucket The story-site workflow adds the stories the published site lacks: it plans from the master data of moenotes-masterdata-sync against the bucket's story manifests, builds the missing stories with `nnnotes web --story` on top of the fetched manifests (fonts, tools, player and APK pinned), rewrites the indexes with `--player-only`, and uploads new assets, then manifests, then the indexes; it never deletes. Triggered by the masterdata-updated dispatch, daily, or by hand (story ids, force, dry run). Everything is under .github/, so the fork keeps syncing with upstream. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…ned ranged downloads were rejected by Cloudflare occasionally) The fetch step downloaded every manifest with S3's signed download_file (ranged), which Cloudflare's edge intermittently answered with SignatureDoesNotMatch. The bucket serves public read anyway and plan already lists it anonymously, so fetch now GETs each file with the same client plan uses; publish keeps its signed uploads. Co-Authored-By: Claude Code <noreply@anthropic.com>
Co-Authored-By: Claude Code <noreply@anthropic.com>
…ch has no manylinux x86_64 wheel) UnityPy 1.25.0 declares Requires-Dist: etcpak, but etcpak's PyPI project ships neither manylinux x86_64 wheels nor a source build usable on a fresh Ubuntu runner with Python 3.13, so pip fails with 'no matching distribution' while 1.25 is the resolved version. The runner's UnityPy build has always been from sdist anyway; 1.24.2 publishes one and does not need etcpak. Co-Authored-By: Claude Code <noreply@anthropic.com>
pip 26's new resolver pins a cached unitypy==1.25.3 into the editable install's constraint set, which conflicts with the required etcpak (which has no manylinux x86_64 wheel on the runner's Python 3.13). uv's resolver does not carry pip's installed set into a fresh venv and picks unitypy==1.24.2, which is what pyproject.toml already allows. The two pip install steps (plan's boto3, build's editable install) now go through astral-sh/setup-uv with --system. Co-Authored-By: Claude Code <noreply@anthropic.com>
The upstream CI workflow (push to main) was still using pip and its goldens job pinned UnityPy==1.25.3, which cannot resolve on the runner because etcpak has no manylinux x86_64 wheel. Install through uv like the story-site workflow and pin goldens to the 1.24 line. Co-Authored-By: Claude Code <noreply@anthropic.com>
UnityPy 1.25.3's PyPI metadata originally required etcpak (which has no manylinux x86_64 wheel), but the current metadata for the same version declares tpk-ar instead. pip 26's resolver keeps the stale etcpak requirement in its cache and fails, while uv fetches the fresh metadata and resolves UnityPy 1.25.3 cleanly. Stay on >=1.25 and let uv handle it. Co-Authored-By: Claude Code <noreply@anthropic.com>
.github/workflows/music-data.yml runs `nnnotes music-data --decoded-master` on moenotes-masterdata-sync's decoded master data, the way the story site workflow reads it, and publishes the file for the chart data page into the story site's bucket under music-data/: music-data.json, jackets/, archive/<master version>/<sha256>.json and the build marker build.json. It reuses the story site's triggers (repository_dispatch masterdata-updated, a daily schedule, workflow_dispatch with force and dry_run), its plan/build jobs, secrets, bucket and helpers (story_site.py, apk.sh); no new secret, no master key. plan compares the master data snapshot, the pinned deck commit, the last nnnotes commit and the script's recipe with the published build.json and ends there when nothing changed. build checks the file before anything is uploaded: the JSON Schema, provenance against the snapshot and its manifest, no fewer songs or charts, complete deck statistics and play scenario fields, finite numbers, references and texts, BGM lengths, 0.8 to 2 times the published size, and a smoke test with the chart data page's own modules (MUSIC_DATA_PLAYER_REF, to be set). The jackets and the archive copy go first, music-data.json next, build.json last, each read back by SHA-256. The gate self-test (test_music_data.py) runs in every build and locally in seconds. The workflow needs the fork synced with upstream nnnotes (music-data with the play scenarios and --decoded-master): .github/MUSIC_DATA.md. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Upstream MetaSekaiLab/nnnotes main 12df2a6: 0.1.2, the music-data command with the deck model nnnotes._deck (Rust, maturin), its play scenarios and --decoded-master. ci.yml: upstream's actions, Rust cache and rust job, with this fork's uv installs. story-site.yml: the Rust cache for the install, which now builds nnnotes._deck. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A publishing switch, the repository variable MUSIC_DATA_PUBLISH (unset: off): unless it is `true` every run of music-data.yml, whatever its trigger, is a dry run. It builds, runs every gate and the page smoke test and lists what it would upload; the publish step gets no bucket key, and `music_data.py publish` itself refuses to upload. MUSIC_DATA.md says how to turn it on. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
chore: sync with upstream nnnotes main (12df2a6)
ci: build, check and publish the music data file on new master data (publishing off until MUSIC_DATA_PUBLISH is true)
feat(jp): support Japanese release assets and split APKs
fix(jp): reject incomplete downloads and isolate APK updates
The deck gate checks the seeds (the one seed 0 on a chart without a luck range, else two or more different seeds, the same on every luck chart: their number is the file's, not fixed), every seed range's rank 1 bonus (trunc(rangeScore * rankBonusPercent / 100)) and its luckPoints, which nnnotes and ournotes-deck add with the Gekisou skills. RECIPE 2. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Check shape references, mission coverage, band variants, mean/error pairs, seed rules, dimensions, tail identities and simulation bounds. Cap gzip size at 2 MB overall and 1.2 MB for aptitude. Exercise page lookups, gains, uncertainty and missing cross terms. Default figures must remain unchanged. Reconstruct only deterministic check seeds with positional master skill factors, never stochastic means. Add a real chart-stats sample test and a necessary rounding bound for stochastic tailPerfect. Keep production PLAYER_REF and publishing unchanged. Co-Authored-By: Claude Code <noreply@anthropic.com>
ci: validate music data Gekisou aptitude and gzip size
Exmeaning
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.