Merge pull request #53 from dandwhelan/claude/predbat-sync-mobile-ui-562ys9

Mobile UI fix + merge upstream v8.54.0

Author: dandwhelan

.claude/skills/issue-pr/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: issue-pr
+description: Implement the fix or feature described in an already-triaged batpred GitHub issue and open a draft pull request referencing it, for maintainer review.
+allowed-tools: You can view and edit files in this repo, write code and tests, run local tests and pre-commit, commit and push a new branch, and open a draft pull request with 'gh'. Do not merge, close, or push directly to main.
+---
+
+# Issue PR
+
+You are implementing the fix or feature described in one already-triaged GitHub issue on `springfall2008/batpred`, and opening a draft pull request for maintainer review. The working directory is the same dedicated local clone the triage skill uses — investigate and work using it directly.
+
+Arguments: `<issue-number> [scratch=<dir>]`, same convention as `/issue-triage`. If no `scratch=` is given (an interactive invocation), use `/tmp/predbat-triage/<issue-number>` and `mkdir -p` it yourself.
+
+This skill assumes the issue has already been triaged — the daemon only invokes it once that's confirmed. Read the existing triage comment before doing anything else.
+
+## 1. Read the ticket
+
+Fetch it with `gh issue view <number> --json title,body,labels,comments`. The bot's own triage comment (opens with "automated first-pass triage") already has the classification, priority, and any root-cause pointer — start from there rather than re-investigating from scratch.
+
+## 2. Investigate
+
+- Sync the clone first, so you are reading the code you think you are:
+
+  ```bash
+  git fetch origin main && git reset --hard origin/main && git clean -fd
+  git describe --tags
+  ```
+
+- Read [../issue-triage/references/debug-journal.md](../issue-triage/references/debug-journal.md) before forming an implementation approach — it maps common symptoms to modules and records known per-integration behaviour from past investigations. Its entries are dated observations, not current truth — confirm anything you rely on against the working tree.
+- Read the relevant source area named in the triage comment's root-cause pointer, or that the issue's classification points to.
+- Check `git log`/`git blame` on that area — the triage comment may already cover this, but confirm nothing has changed on `main` since triage ran.
+
+## 3. Implement
+
+- Write the fix or feature following this repo's conventions (`CLAUDE.md`, already loaded automatically for this session): `lower_case_with_underscores` naming, 256-character line length, a one-line docstring on every new function or class.
+- Add or update a unit test for the change, in the matching `apps/predbat/tests/test_<feature>.py` module (registered in `TEST_REGISTRY` in `apps/predbat/unit_test.py` if it's a new module) — `CLAUDE.md` requires unit tests for all new code, no exceptions for bot-authored ones.
+- Keep the change scoped to what the issue describes. Don't refactor unrelated code, even if you notice something else worth fixing.
+
+## 4. Quality gate
+
+Both of these must pass before you continue to step 5. `run_pre_commit` must run with `coverage/` as the working directory (it sources `coverage/setup.csh` internally); `tools/triage_test.sh` must run from the repo root. Change directory explicitly for each rather than assuming where you're left afterwards:
+
+```bash
+cd coverage
+./run_pre_commit
+cd ..
+tools/triage_test.sh <name> <scratch>/test.log
+```
+
+Use the test module named in the triage comment, or the one `TEST_REGISTRY` maps to the area you changed. If there's no clean single-module mapping, run `./run_all --quick` instead (from `coverage/`, same as above) rather than guessing at a module name.
+
+If either fails, stop here — do not commit, push, or open a PR. Go to step 7 and report what failed.
+
+## 5. Branch, commit, push
+
+Branch name: `fix/<slug>-<issue-number>` for a `bug` classification, `feat/<slug>-<issue-number>` for `enhancement` — matching this repo's existing convention (e.g. `fix/solis-tou-bit-refused-4707`). `<slug>` is a short kebab-case description of the change.
+
+```bash
+git checkout -B fix/<slug>-<issue-number>
+git add <changed files>
+git commit -m "<one-line summary of the fix>"
+git push -u origin fix/<slug>-<issue-number>
+```
+
+`-B` rather than `-b`: if a previous attempt reached branch creation and then failed on push or PR creation, the local branch is left behind, and a retry's plain `-b` would fail with "branch already exists." `-B` resets it to the current `HEAD` instead, so a retry always starts clean.
+
+Never push to `main`, and never force-push.
+
+## 6. Open the draft PR
+
+```bash
+gh pr create --draft --assignee springfall2008 \
+  --title "<one-line summary>" \
+  --body "$(cat <<'EOF'
+This is an automated draft PR generated from issue #<issue-number> — a maintainer should review it before merging.
+
+Fixes #<issue-number>
+
+## Summary
+
+<what changed and why, in a sentence or two>
+
+## Testing
+
+<what you ran in step 4 and its result>
+
+## Notes
+
+<a debug-journal.md reference if one informed the approach, otherwise omit this section>
+EOF
+)"
+```
+
+This is the last step on success — there is nothing further to report; the daemon detects the new PR itself.
+
+## 7. On failure
+
+If step 4's quality gate failed, or an earlier step couldn't proceed (e.g. the fix genuinely needs information only a maintainer has), post exactly one comment on the issue via `gh issue comment <number> --body "..."` explaining plainly what you attempted and what failed — never word it so a skipped step reads as one you completed (same guardrail as the triage skill). Then stop. Do not commit, push, or open a PR — the daemon detects this outcome itself by finding no PR referencing the issue afterwards.
+
+## Guardrails
+
+- Never push to `main` or force-push.
+- Never merge, close, or edit an existing PR.
+- Never remove a label a human applied.
+- The PR is always a draft — never open it as ready-for-review.
+- If a command you needed was blocked by permissions, say plainly in the failure comment what you could not do.

.claude/skills/issue-triage-followup/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: issue-triage-followup
+description: Re-review an already-triaged batpred GitHub issue in light of information added since the original triage, and post a follow-up comment updating the assessment if warranted.
+allowed-tools: You can view and edit files in this repo, run local tests, download and grep issue attachments, access the issue in github with 'gh' and use git commands to check history and re-sync the clone. Do not go outside this sandbox or push any changes back to git.
+---
+
+# Issue Triage Follow-up
+
+You are re-reviewing one already-triaged GitHub issue on `springfall2008/batpred`, incorporating anything added since the bot's previous triage comment. The working directory is a dedicated local clone of the repo — investigate using it directly.
+
+Arguments: `<issue-number> [scratch=<dir>]`, same convention as `/issue-triage`. If no `scratch=` is given (an interactive invocation), use `/tmp/predbat-triage/<issue-number>` and `mkdir -p` it yourself.
+
+## 1. Read the issue and find what's new
+
+Fetch it with `gh issue view <number> --json title,body,labels,comments`. Find the bot's most recent prior comment (opens with "automated first-pass triage" or "automated follow-up triage review"). Everything posted **after** that comment — reporter replies, new logs, a maintainer's note — is the new information this review exists to act on.
+
+If there's nothing posted since the last bot comment, say so plainly in your follow-up comment rather than inventing a reason to change anything.
+
+## 2. Fetch any new attachments
+
+Same as `/issue-triage` step 2: if the new information links a log file, a `predbat_debug.yaml`, or a zip of either, download it into the scratch directory and size/grep it rather than reading it whole.
+
+## 3. Re-investigate against current main
+
+- Sync the clone first, so you are reading the code you think you are:
+
+  ```bash
+  git fetch origin main && git checkout main && git reset --hard origin/main && git clean -fd
+  git describe --tags
+  ```
+
+- Read [../issue-triage/references/debug-journal.md](../issue-triage/references/debug-journal.md) before revising your assessment.
+- Re-check `git log`/`git blame` on the relevant area — the fix may have landed on `main` since the original triage.
+- If the new information points at a test module, run it via `tools/triage_test.sh <name> <scratch>/test.log` (never the full suite).
+
+## 4. Decide whether the assessment changes
+
+Compare your updated understanding against the original triage comment's classification, priority, and root-cause pointer:
+
+- If nothing material changed, say so — confirming the original assessment still holds is a legitimate outcome, not a reason to avoid posting.
+- If the classification, priority, or root-cause should change given the new information, update it. You may change or remove a label **you previously applied as the bot** (classification, priority, `waiting_for_user`) — never remove a label a human added.
+- Apply the same duplicate check as `/issue-triage` step 4 if the new information suggests one.
+
+## 5. Post one follow-up comment
+
+Check the comment history first: if the most recent comment is already a bot comment with nothing from a human posted after it, stop — this review already happened and nothing new has arrived since.
+
+Post exactly one comment via `gh issue comment <number> --body "..."`, opening with a line disclosing this is an automated follow-up triage review (a maintainer will review before any action is taken), followed by: what was new since the last review, whether the classification/priority/root-cause changed and why (or confirmation nothing changed), and any further information request.
+
+Do **not** touch the `BOT_TRIAGED` or `BOT_REVIEW` labels — the daemon manages both.
+
+## Guardrails
+
+- Analysis only: no commits, no pushes, no PRs, no code changes that leave this clone.
+- Never remove a label a human applied; you may only revise labels the bot itself applied.
+- Never close an issue except a confident duplicate.
+- If a command you needed was blocked by permissions, say plainly in the comment what you could not do — never word it so a step you skipped reads as one you completed.

.claude/skills/issue-triage/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: issue-triage
+description: Investigate a newly opened batpred GitHub issue against current main, classify it, assign labels and priority, and post a first-pass triage comment.
+allowed-tools: You can view and edit files in this repo, run local tests, download and grep issue attachments, access the issue in github with 'gh' and use git commands to check history and re-sync the clone. Do not go outside this sandbox or push any changes back to git.
+---
+
+# Issue Triage
+
+You are triaging one GitHub issue on `springfall2008/batpred`. The working directory is a dedicated local clone of the repo — investigate using it directly.
+
+Arguments: `<issue-number> [scratch=<dir>]`. The scratch directory is a writable place to download attachments to; it is emptied before each run. If no `scratch=` is given (an interactive invocation), use `/tmp/predbat-triage/<issue-number>` and `mkdir -p` it yourself.
+
+## 1. Read the issue
+
+Fetch it with `gh issue view <number> --json title,body,labels,comments`. Note any labels already applied — never remove a label a human added.
+
+## 2. Fetch attachments
+
+If the body links a log file, a `predbat_debug.yaml`, or a zip of either, download it into the scratch directory rather than pulling it through WebFetch — a `predbat.log` is routinely tens of MB, well past what WebFetch will return.
+
+```bash
+curl -sL "<url>" -o <scratch>/predbat.log
+```
+
+Never `cat` or read a whole log into context. Size it up first, then extract only what matters:
+
+```bash
+wc -l <scratch>/predbat.log
+grep -n "Traceback\|ERROR\|Exception\|Warn" <scratch>/predbat.log | tail -50
+sed -n '<start>,<end>p' <scratch>/predbat.log     # context around an interesting line
+```
+
+The log gives you error/traceback context; the debug yaml gives you the reporter's actual configuration (grep it for the specific keys you care about if it is large). The reporter's Predbat version is usually in the first few lines of the log — quote the version you actually confirmed, not the one in the issue template.
+
+A `predbat_debug.yaml` can also be replayed against current main to reproduce their plan and list every setting they have changed from default — see [references/debug-journal.md](references/debug-journal.md).
+
+## 3. Classify the type
+
+Apply exactly one of: `bug`, `question`, `configuration` (user error/misconfiguration), `enhancement` (feature request). If genuinely ambiguous, apply `unclear` instead of guessing.
+
+## 4. Check for duplicates
+
+Search existing issues (`gh issue list --search ...`, both open and closed) for the same symptom.
+
+- High confidence match: label `duplicate`, comment linking the original issue, and close this one.
+- Low confidence: mention "possibly related to #N" in your triage comment; don't close.
+
+## 5. Investigate against current main
+
+- Sync the clone first and discard anything left over from a previous run, so you are reading the code you think you are:
+
+  ```bash
+  git fetch origin main && git reset --hard origin/main && git clean -fd
+  git describe --tags        # the version you are investigating against
+  ```
+
+- Read [references/debug-journal.md](references/debug-journal.md) before forming a hypothesis. It maps common symptoms to modules, records known per-integration behaviour from past investigations, and lists the traps that have wasted time before. Its entries are dated observations, not current truth — confirm anything you rely on against the working tree.
+- Read the relevant source area for the reported symptom (e.g. `apps/predbat/fetch.py` for rate issues, `apps/predbat/inverter.py` for a named inverter).
+- Check `git log` / `git blame` on that area for recent related changes — the issue may already be fixed on main since the version the reporter is using.
+- If the issue clearly maps to an existing test module (`apps/predbat/tests/test_<feature>.py`, listed in `TEST_REGISTRY` in `unit_test.py`), run just that test with the wrapper, from the repo root:
+
+  ```bash
+  tools/triage_test.sh <name> <scratch>/test.log
+  ```
+
+  It prints the exit status and the last 30 lines; grep the log file for anything more. Use the wrapper rather than composing your own `cd coverage && ./run_all ... > log` — a `cd` combined with an output redirect is refused outright in this session's permission mode, which is why the wrapper exists.
+
+  Skip this step if there's no clean mapping — never run the full suite. A test only settles questions about code behaviour; it can't settle what real hardware did, so don't run one to look thorough.
+
+- Form a root-cause hypothesis with a `file:line` pointer if the investigation supports one. It's fine to say the cause needs maintainer review if it doesn't.
+- You may edit files locally to test a hypothesis (e.g. a temporary debug print, a tweaked test fixture) — this clone is hard-reset and cleaned before the next run, so nothing here persists. Never `git commit` or `git push`.
+
+## 6. Apply component labels
+
+Only when the issue text clearly names a specific inverter or integration (e.g. `solis`, `Huawei`, `solaredge`, `Octopus`, `fox`), apply the matching existing label. Don't guess.
+
+## 7. Check for missing information
+
+For bug reports specifically, verify these four things (from the bug report template) are actually present: Predbat version, inverter/environment details, log file, `predbat_debug.yaml`. If something missing is actually needed for your investigation, apply `waiting_for_user` and ask only for what's missing — don't ask for things already provided.
+
+## 8. Set priority
+
+Apply exactly one of:
+
+- `priority_high` — impacts many users, no workaround
+- `priority_medium` — impacts many users, workaround exists
+- `priority_low` — limited impact or an easy workaround
+
+Skip priority for pure questions and feature requests.
+
+## 9. Post one comment
+
+Check existing comments first — if one from you is already there, stop; don't post again.
+
+Post exactly one comment via `gh issue comment <number> --body "..."`, opening with a line disclosing this is an automated first-pass triage (a maintainer will review before any action is taken), followed by: classification, priority (if set), what you investigated and found (including test result if you ran one), a root-cause pointer if you have one, and any information request.
+
+After posting, apply the `BOT_TRIAGED` label via `gh issue edit <number> --add-label BOT_TRIAGED` — every triage run gets this label, including a duplicate-close, regardless of classification. It marks the issue as triaged for the separate PR-creation flow (see `.claude/skills/issue-pr/SKILL.md`).
+
+## Guardrails
+
+- Analysis only: no commits, no pushes, no PRs, no code changes that leave this clone.
+- Never remove a label a human applied.
+- Never close an issue except a confident duplicate.
+- If a command you needed was blocked by permissions, say plainly in the comment what you could not do — never word it so a step you skipped reads as one you completed.