yau-plant-assistant/status/OPEN-ISSUES.md
Claude a627fa5ac7 Log the no-setpoint rule as a decision to revisit, and widen the register
OI-02: the second of the three lines this system does not cross - no
recommended setpoints or operating parameters - is expected to come up as
a feature request. An Advisory answer gives evidence, ranges, outcomes and
documented limits, then defers to a competent person, and never returns a
number as the answer. There is a foreseeable case for allowing it, and the
conversation should start from what is built rather than from scratch.

The entry records where the rule actually lives, because it is a code path
and not a prompt instruction, so relaxing it is a change in four places at
once: AdvisoryAnswer's recommendation_given: Literal[False] and required
deferral in api/contracts.py, the classifier routing anything
partly-advisory to the class that refuses to advise, 14 Advisory cases in
the eval set, and 15 tests. It also records what has to be decided before
any of that is touched - who is accountable for the number, what evidence
is sufficient when the historian shows what happened rather than what the
plant can safely do now, and how a recommendation is told apart from a
documented limit on screen.

It is blocked by the OT/safety review of section 2 of the build spec,
which is still outstanding. That review will have the strongest opinion on
this rule of anything in the document, so the rule should not be relaxed
before it happens.

The register's header said it held work we "intend to do", and its
boundary table admitted only defects. OI-02 is neither: the rule works as
designed. Rather than let the register's rules and its contents disagree -
which is the failure this register exists to prevent - the header now
covers decisions we expect to revisit, and the table has a row for them
requiring the entry to be marked "not a defect".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-01 19:56:54 +10:00

119 lines
5.9 KiB
Markdown

# Open issues — WRPS Plant Assistant
**Work we own, and decisions we expect to revisit.** One entry per issue, newest first.
Nothing here is assigned yet; owners are set at handover.
## What belongs here, and what does not
This repository has three other registers. Putting an item in the wrong one is how
a repository ends up saying two different things about the same fact.
| If it is... | It goes in | Not here |
|---|---|---|
| Waiting on somebody outside this project | [`REQUESTS.md`](REQUESTS.md) | ✗ |
| A shortcut we **consciously accepted** | [`BUILD-AI-CONTAINERS.md`](../spec/BUILD-AI-CONTAINERS.md) §14 | ✗ |
| Something already running, and its state | [`current-state.html`](current-state.html) | ✗ |
| **A defect or gap we own and have not fixed** | **here** | ✓ |
| **A design decision we expect to revisit** | **here**, marked *not a defect* | ✓ |
Three rules:
1. **Anything in §14 is closed by decision.** It was weighed and accepted. Do not
re-open it here — `caddy/ai-routes.caddy` carries one such decision explicitly
marked *"do not re-raise this as a task"*.
2. **If an issue is a defect in something that already passed a phase gate**, fixing
it means re-running that gate. `CLAUDE.md` requires it; say so in the issue.
3. **Closed issues move to the bottom, they are not deleted.** The register is part
of the as-built record, and an issue with no trace of how it closed is worth less
than one that was never raised.
---
## Open
### OI-02 · The no-setpoint rule may need to become optional
**Raised** 2026-09-01 · **Owner** unassigned · **Affects** the product, not the build ·
**Not a defect** — the rule works as designed. Logged because it is a design decision that
is expected to be revisited.
The second of the three lines this system does not cross is **no recommended setpoints or
operating parameters**. An Advisory answer gives evidence, ranges, outcomes and documented
limits, then defers explicitly to a competent person. It never returns a number as the answer.
There is a foreseeable case for allowing it — a recommendation is the thing an operator
actually wants, and withholding it has a cost. This entry exists so that conversation starts
from what is built rather than from scratch.
**Where the rule lives.** It is not a prompt instruction, so relaxing it is a code change in
several places at once:
| Enforcement point | What it does |
|---|---|
| `api/contracts.py``AdvisoryAnswer` | `recommendation_given: Literal[False]` — the contract cannot express a recommendation. A `deferral` string is required, and a scope banner is attached to every Advisory answer |
| `api/classifier.py` | Advisory beats Historical; partly-advisory is advisory. Anything that could be read as advice is routed to the class that refuses to advise |
| `eval/testset.jsonl` | 14 Advisory cases assert the refusal |
| `api/tests/` | 15 tests across contracts and classifier rules |
**What would have to be decided before it changes** — none of this is a coding question:
- **Who is accountable for a number the assistant produces**, once it stops deferring. Today the
deferral is what keeps that answer unambiguous.
- **What evidence is sufficient.** The rule exists because "best" depends on equipment condition
and concurrent operations this system cannot see — the historian shows what happened, not what
the plant can safely do now.
- **How a recommendation is distinguished on screen** from evidence, so it cannot be misread as a
documented limit.
- **Whether it applies to all parameters or a named subset**, and who approves that list.
- **§2 of the build spec is still awaiting an OT/safety review.** This rule is the largest single
thing that review will have an opinion on. Do not relax it beforehand.
**Blocked by** the OT/safety review of `spec/BUILD-AI-CONTAINERS.md` §2, which is outstanding.
**Blocking** nothing.
---
### OI-01 · OpenPLC Editor is not installed
**Raised** 2026-09-01 · **Owner** unassigned · **Affects** the demo plant, not the assistant
The **OpenPLC Editor** — a desktop tool published by the OpenPLC project, installed on a
workstation — is the application used to author and compile the IEC 61131-3 program that
`openplc-runtime` executes. It is not installed anywhere. It talks to the running container
over its REST API on port `8443`, bound to `10.0.0.17`.
**Why it matters.** `openplc-runtime` is live control for this demo: `CLAUDE.md` and
[`BUILD-AI-CONTAINERS.md`](../spec/BUILD-AI-CONTAINERS.md) §4 both forbid reconfiguring it
as a side effect of other work. Without the Editor there is no way to author, review or
compile the control logic — and no reviewable source for it in or beside this repository.
The program exists only inside the container. If the container is lost, so is the logic.
**What port 8443 is** — probed read-only on the host 2026-09-01, because two earlier
statements in the build spec called it a web UI and were wrong:
```
Server: Werkzeug/3.1.8 Python/3.11.2
/ /login /index.html /programs /status /runtime -> 404
/api/v1 -> 401 Unauthorized
```
An authenticated REST API. No browser interface. Both build-spec statements were corrected
in the commit that raised this issue.
**Open questions to settle when this is picked up.**
- **Which workstation.** Not `lin001` — the Editor is a desktop application. Not `cicore1`
`CLAUDE.md` forbids installing anything on it. That leaves an engineering workstation with
VPN or LAN reach to `10.0.0.17:8443`.
- **Credentials for `/api/v1`**, which currently answers `401`. Not held by this project.
- **Whether the PLC program goes under version control**, and where. This is the part that
closes the "logic exists only in the container" gap, and it is the reason this issue is
worth more than "install a tool".
**Blocked by** nothing. **Blocking** nothing today — the demo runs.
---
## Closed
*None yet. Closed issues move here with the commit that closed them.*