6 Commits
Author SHA1 Message Date
Claude 59a6ffc940 CLAUDE.md: local build, Gitea shipping flow and Katan rule sets
CI / Build and check (push) Successful in 8m6s
CI / Deploy to Cloudflare Pages (push) Successful in 29s
CI / Build and check (pull_request) Successful in 8m13s
CI / Deploy to Cloudflare Pages (pull_request) Skipped
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_016eTor2tpxKb4dXbd8RqnvZ
2026-10-17 18:31:29 +00:00
Claude ad30ab9dea Move CI to Gitea: run-number offset, Cloudflare-only publishing
- plgVersionRunOffset=1000: stamped build number is run number + offset, so
  Gitea's restarted run counter cannot produce a versionCode below an
  installed one (GitHub reached prod 30, dev ~172). Tags and versionName use
  the same number.
- Drop the GitHub release steps; plg.wallacenet.ca is the only channel.

Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01JdMNbY5hLR7FjtfEE712xG
2026-10-14 17:00:01 +00:00
Claude af6f27cf60 Filter bash output through rtk before it reaches the model
Register a PreToolUse hook on Bash that rewrites each command through rtk,
so `git status` runs as `rtk git status` and the output is compressed on the
way back. The rewrite is transparent; commands are still written normally.

Measured on this repo, a full `git diff HEAD~3` drops from 521 KB to 28 KB,
a recursive grep over app/src/main from 117 KB to 19 KB, and `git log -20`
from 20 KB to 5.3 KB. Small outputs grow marginally because rtk adds a
header, which at those sizes is not worth avoiding.

The container starts empty, so a SessionStart hook installs the binary first.
It pins RTK_VERSION because the installer's default is to resolve the latest
tag through api.github.com, which the proxy answers 403 for every repository
but this one. Outside the sandbox the hook installs nothing and only prints
the command to run, and every failure path exits clean: with rtk absent the
rewrite no-ops and the only cost is verbose output.

Verified that rtk leaves what must not change alone -- `rtk read` returns
GameSetupScreen.kt byte-for-byte, commit messages keep their quoting, and
already-rewritten commands are not wrapped twice.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Urn6eEBA6XzrnfoibL7faC
2026-08-08 04:30:36 +00:00
Claude e8c7162bc0 Move to the 1.1 series, from one place rather than three
The series a build is named for was written out three times — in the
build file and in both workflows' tag lines — so bumping it meant
changing all three and a release could be tagged one thing and built as
another. It now lives in gradle.properties as plgVersionSeries, which
the build reads when it stamps the APK and both workflows read when they
name the tag.

Set to 1.1.

versionCode is deliberately left as the CI run number alone, which is
what makes the bump safe: the run number keeps climbing across a change
of series, so 1.1 never looks like a downgrade to Android and an OTA
update is not interrupted. The series is a name for people; the run
number is what the machines compare. The updater already read only the
trailing number, and its comments now say so rather than naming 1.0.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_019Pr6B8xDDtJJcb6WJMw7Ud
2026-08-07 15:50:30 +00:00
Claude 625a130366 Correct the rule: pull requests do not trigger CI either
Opening this pull request through the API produced no workflow run, so
the previous version of this file was wrong about the API route being
the fix. The suppression covers everything the sandbox does — pushes,
pull request opens, and merges — because it follows the integration, not
the account the UI attributes the action to.

workflow_dispatch is the only mechanism that works, because it creates a
run directly rather than relying on an event.

Record the loop that follows from that, including the part worth having:
ci.yml gates only its staging and publishing steps on refs/heads/dev, so
dispatching it on a feature branch runs build, tests and lint while
publishing nothing. That is a real pre-merge gate with no YAML changes.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01YEsqYAMJKUJoM7UAavm169
2026-08-06 22:18:24 +00:00
Claude 9c9a40303e Add CLAUDE.md recording how changes must reach CI
A git push from a Claude session is made with a bot token, and GitHub
creates no workflow run for it — the branch moves and CI stays silent.
Today that put a change on dev and then main having only ever been built
after the fact, and both branches needed a manual workflow_dispatch to
produce anything.

Record the working rule that avoids it: push the feature branch, then
open and merge the pull request through the GitHub API, whose calls are
attributed to the repo owner and do trigger workflows. ci.yml already
listens on pull_request for main and dev, so the PR is what builds the
change before it lands.

Also note what a merge actually does here — dev publishes a dev-channel
prerelease, main publishes a production release — and that Gradle cannot
run in the sandbox, so CI is the only verification available.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01YEsqYAMJKUJoM7UAavm169
2026-08-06 22:13:52 +00:00