120 lines
5.4 KiB
YAML
120 lines
5.4 KiB
YAML
name: Nightly Architectural Sweep
|
|
|
|
on:
|
|
schedule:
|
|
# 4:00 AM CST daily, inspired by the Aarete DocyAI architectural sweep cadence.
|
|
# Gitea schedules use UTC. CST (UTC-6): 10:00 UTC.
|
|
# During CDT this runs at 5:00 AM America/Chicago unless the cron is adjusted.
|
|
- cron: '0 10 * * *'
|
|
workflow_dispatch:
|
|
|
|
jobs:
|
|
create-architectural-sweep-issue:
|
|
name: Create Architectural Sweep Issue
|
|
runs-on: ubuntu-latest
|
|
|
|
steps:
|
|
- name: Create architectural sweep issue
|
|
run: |
|
|
python3 - <<'PYEOF'
|
|
import json
|
|
import urllib.request
|
|
from datetime import datetime, timezone
|
|
|
|
gitea_api = "http://100.79.253.19:3000/api/v1"
|
|
repo = "${{ gitea.repository }}"
|
|
token = "${{ gitea.token }}"
|
|
run_url = "http://100.79.253.19:3000/${{ gitea.repository }}/actions/runs/${{ gitea.run_id }}"
|
|
today = datetime.now(timezone.utc).strftime("%Y-%m-%d")
|
|
|
|
body = f"""## Architectural Sweep - {today}
|
|
|
|
Daily architecture review for **Throne of the Bone King**.
|
|
|
|
This follows the Aarete DocyAI sweep pattern: each domain should be reviewed independently, findings should be posted as separate comments, and critical issues should become focused follow-up tickets before moving on.
|
|
|
|
**Action run:** {run_url}
|
|
|
|
---
|
|
|
|
> Agent instructions:
|
|
>
|
|
> Post a separate comment for each domain as soon as that domain is complete.
|
|
> Title comments with the domain and date, for example `Architecture Findings - {today}`.
|
|
> Link follow-up issues from this sweep and include file paths or commands where relevant.
|
|
|
|
---
|
|
|
|
### 1. Shared App Architecture
|
|
|
|
- [ ] Review `App.tsx`, `src/navigation/AppNavigator.tsx`, and `src/components/GameViewport.tsx`.
|
|
- [ ] Confirm shared React Native code is still platform-safe and free of DOM-only APIs.
|
|
- [ ] Check whether navigation, transitions, safe area, and fixed landscape viewport boundaries remain cleanly separated.
|
|
- [ ] Identify any component that is taking on too many responsibilities.
|
|
|
|
### 2. State and Persistence
|
|
|
|
- [ ] Review Zustand stores in `src/state/`.
|
|
- [ ] Confirm persisted route and settings state can recover from stale or legacy values.
|
|
- [ ] Check that platform storage remains isolated to `persistStorage.ts` and `persistStorage.web.ts`.
|
|
- [ ] Look for race conditions between route transitions, socket connection updates, and Toolkit content refreshes.
|
|
|
|
### 3. Toolkit and Socket Sync
|
|
|
|
- [ ] Review `src/screens/ToolkitScreen.tsx`, `src/socket/toolkitSocketClient.ts`, and `socket/server.mjs`.
|
|
- [ ] Confirm Toolkit access is still Browser-resolution and socket-gated.
|
|
- [ ] Verify content read/save/change/error paths remain typed and tested.
|
|
- [ ] Identify the next volatile gameplay content area that should use the socket-backed JSON pattern.
|
|
|
|
### 4. Data, Content, and Gameplay Loops
|
|
|
|
- [ ] Review `src/data/`, `wiki/`, and Toolkit route coverage.
|
|
- [ ] Check that petitioners, rulings, seed logic, resources, factions, flags, story arcs, lore, audio, endings, and references still map to future gameplay loops.
|
|
- [ ] Identify mismatches between wiki expectations and app/toolkit scaffolding.
|
|
- [ ] Recommend one schema or fixture that should be formalized next.
|
|
|
|
### 5. UI, Layout, and Assets
|
|
|
|
- [ ] Inspect Home, Settings, Policies, Credits, and Toolkit layouts against fixed landscape resolutions.
|
|
- [ ] Check for accidental scrolling, clipped text, oversized controls, or insufficient contrast.
|
|
- [ ] Review `src/assets/` usage, font loading, favicon, menu art, and background music.
|
|
- [ ] Flag any asset size or bundling risk that affects web/Electron builds.
|
|
|
|
### 6. Test and Build Health
|
|
|
|
- [ ] Run or review `npm run lint`.
|
|
- [ ] Run or review `npm run test -- --runInBand`.
|
|
- [ ] Run or review `npm run electron:build`.
|
|
- [ ] Identify missing tests for any recent architecture change.
|
|
- [ ] Scan for TODO/FIXME/HACK/TEMP, empty catches, broad casts, dead exports, or stale docs.
|
|
|
|
### 7. Technical Debt and Next Actions
|
|
|
|
- [ ] List concrete architecture risks with severity and owner recommendation.
|
|
- [ ] Estimate effort for each fix as S, M, or L.
|
|
- [ ] Create follow-up issues for any item that should not wait for the next sweep.
|
|
- [ ] Pick the single most valuable architecture improvement for the next work session.
|
|
|
|
---
|
|
|
|
_Auto-generated nightly by Gitea Actions._"""
|
|
|
|
payload = {
|
|
"title": f"Architectural Sweep - {today}",
|
|
"body": body,
|
|
}
|
|
|
|
req = urllib.request.Request(
|
|
f"{gitea_api}/repos/{repo}/issues",
|
|
data=json.dumps(payload).encode("utf-8"),
|
|
headers={
|
|
"Authorization": f"token {token}",
|
|
"Content-Type": "application/json",
|
|
},
|
|
method="POST",
|
|
)
|
|
with urllib.request.urlopen(req, timeout=20) as response:
|
|
result = json.loads(response.read())
|
|
print(f"Created issue #{result['number']}: {result['html_url']}")
|
|
PYEOF
|