Commit Graph
7 Commits
Author SHA1 Message Date
adrianoftyrielandPaperclip b58b4251dc Rename the Gitea repo references to ProLibertateGames
Build and Release APK / Build APK and publish release (push) Canceled after 0s
The repo was renamed from PilgrimsOfKatan to ProLibertateGames on the
Gitea instance. Update every reference so nothing points at the old name:

- OTA updater: the repo constant and the User-Agent
- publish-release.sh: the default repo, the asset name, the release title
- CI/release workflows: the artifact names and the staged APK name
- settings.gradle.kts: the Gradle project name
- Protocol.kt / LanTransport.kt: the mDNS service label and the Wi-Fi lock tag
- docs (README, CLAUDE.md, docs/CI.md) and the update-policy test fixtures

The installed applicationId is left unchanged in this commit.

Co-Authored-By: Paperclip <[email protected]>
2026-10-14 14:21:43 +00:00
adrianoftyrielandPaperclip 5c797c8807 Restore the Pro Libertate Games title and splash; list Katan under Board Games
Build and Release APK / Build APK and publish release (push) Canceled after 0s
The bootstrap rebranded the app to Pilgrims of Katan (WALA-118 review);
the decision is to keep the upstream's own identity instead.

- Title and splash: the upstream originals restored exactly — the Wallace
  tartan splash under the "Pro Libertate Games" uncial wordmark
  (SplashScreen.kt, Tartan.kt), the tartan launcher icon, and the
  Theme.ProLibertateGames window theme. The game screens go back to the
  upstream WallaceGold/WallaceRed accents the tartan is woven from.
- Names and colours: launcher names back to "Pro Libertate Games" /
  "Pro Libertate Games DEV"; the channel colours back to the clan red /
  hunting green setts (resValue tartan_field and friends). The installed
  identity stays ca.wallacenet.pilgrimsofkatan (+ .dev) — that is the
  package, not the brand.
- Catalogue: Katan is listed under Board Games (3-4 players, original
  blurb, no third-party marks) with available = false, so dev builds show
  it as "Coming soon" and a production build hides it until its engine
  and screen land.
- Docs: README/CLAUDE.md/docs/CI.md updated to the restored identity;
  CatalogTest's invariant now names Katan as the one deliberate exception
  rather than asserting nothing is unfinished.

Structural bootstrap untouched: applicationId, OTA repointed at the Gitea
releases, CI workflows, version stamping.

Verified: ./gradlew assembleDebug and testDebugUnitTest green — 628 tests,
0 failures.

Co-Authored-By: Paperclip <[email protected]>
2026-10-14 02:15:30 +00:00
adrianoftyrielandPaperclip fad4778ad8 Bootstrap Pilgrims of Katan: rebrand, Gitea CI and OTA
Build and Release APK / Build APK and publish release (push) Canceled after 0s
Import of ProLibertateGames (upstream main, GPL-3.0) rebranded for
Wallacenet and repointed at git.wallacenet.ca.

- Identity: applicationId ca.wallacenet.pilgrimsofkatan (+ .dev for the dev
  channel), launcher names "Pilgrims of Katan" / "Pilgrims of Katan DEV",
  neutral hexagon branding replacing the Wallace tartan. Uncial Antiqua keeps
  its OFL licence, and the GPL-3.0 LICENSE plus upstream attribution stay.
- OTA: Updater.kt now reads this repo's own Gitea releases
  (/api/v1/repos/devadmin/PilgrimsOfKatan/releases...) and BuildConfig.
  OTA_ENABLED is on; Gitea answers the same JSON shape the code already parsed.
- Build numbers: versionCode = CI run number + plgVersionRunOffset (1000),
  with the tag and versionName derived from the same figure. The offset is
  permanent, because Gitea Actions restarts run numbers at 1 and a reset would
  otherwise make Android reject the next build as a downgrade.
- CI: ci.yml publishes a dev prerelease from dev, release.yml a production
  release from main, both through scripts/publish-release.sh (Gitea REST API,
  runnable by hand until an Actions runner is registered).
- Docs: docs/CI.md records the channel, numbering and runner decisions;
  docs/README.md seeds the per-game RULES-* conventions; CLAUDE.md carries the
  agent ground rules.

Verified: ./gradlew assembleDebug and testDebugUnitTest green on JDK 17 /
compileSdk 34, both variants stamped, installing side by side under the new
identity.

Co-Authored-By: Paperclip <[email protected]>
2026-10-13 22:03:27 +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