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>

status/OPEN-ISSUES.md

@@ -1,6 +1,6 @@
 # Open issues — WRPS Plant Assistant
 
-**Work we own, know about, and intend to do.** One entry per issue, newest first.
+**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
@@ -14,6 +14,7 @@ a repository ends up saying two different things about the same fact.
 | 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:
 
@@ -30,6 +31,48 @@ Three rules:
 
 ## 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