docs(openspec): say what "reuse" means for each of the three

Review feedback on #235. D1 claimed `submitRule`, `pollRuleStatus` and
`writeRuleFile` are "reused, not reimplemented", and for two of the
three that is not true yet.

Both requesters are hardcoded to the rule-family endpoints and take a
required `token`, which `createApiClient` turns unconditionally into an
`Authorization: Bearer` header. The demo is unauthenticated by
requirement, so neither is usable as written. The path half resolves
itself when the client adopts the renamed family; the token half does
not, and is the durable part.

The reason this is worth more than the wording: D1's failure test says
"if the demo needs a new writer, the shapes have diverged, and the demo
has done its job by failing". That test is a claim about PAYLOAD SHAPES,
and it was already tripping — for the requester and the poller, where it
means nothing of the kind. A requester needing a second argument says
nothing about whether the demo and the mainline agree on what a rule
looks like.

So D1 now splits them. `writeRuleFile` is byte-for-byte reuse and is
what the failure test is really about. The other two are two small
changes to functions written when every caller was authenticated, and
they are planned as task 1.2a rather than discovered mid-implementation,
which is what the previous wording set up.

1.2b is the part nobody raised: an unauthenticated call must send no
`Authorization` header rather than one carrying an empty token. A header
the service then has to decide how to ignore is a worse contract than
its absence.

Author: theCodeDrift

openspec/changes/runtime-demo-path/design.md

@@ -51,9 +51,32 @@ demo uses would demonstrate something no user is on. Mirroring also means the
 demo covers polling and the terminal `failed` and `unsupported` states for
 free, because it is the same client code reaching them.
 
-Concretely: `submitRule`, `pollRuleStatus` and `writeRuleFile` are reused, not
-reimplemented. If the demo needs a new writer, that is evidence the shapes have
-diverged, and the demo has done its job by failing.
+Concretely, and the three are not equal — saying "reuse" without splitting them
+would make the failure test below fire for a reason it was not built to catch.
+
+**`writeRuleFile` is reused byte for byte, and it is what the test is about.**
+It carries the path checks, the completeness rules, the layout validation and
+the refusal to write a runtime rule with no captures. **If the demo needs a
+different writer, the payload shapes have diverged**, and the demo has done its
+job by failing. That is the signal worth having, and it is the whole reason for
+mirroring the delivery variant.
+
+**`submitRule` and `pollRuleStatus` need work first, and that is a task rather
+than a divergence signal.** Both are hardcoded to the rule-family endpoints and
+both take a required `token`, which `createApiClient` turns unconditionally into
+an `Authorization: Bearer` header. The demo is unauthenticated by requirement
+(D3), so neither is usable as it stands: the endpoint has to be a parameter, and
+the token has to be optional.
+
+The path half of that resolves itself when the client adopts the renamed family,
+which is out of scope here. The token half does not, and is the durable part.
+Neither is evidence of anything having gone wrong — they are two small changes
+to functions written when every caller was authenticated, and they are planned
+in task 1.2a rather than discovered during implementation.
+
+The distinction matters because D1's failure test is a **claim about payload
+shapes**. A requester that needs a second argument says nothing about whether
+the demo and the mainline agree on what a rule looks like.
 
 ### D2 — The demo tracks the mainline's naming, and follows rather than leads
 

openspec/changes/runtime-demo-path/tasks.md

@@ -30,6 +30,8 @@ what produced the seam this change is closing.
 
 - [ ] 1.1 Add the demo endpoints to `src/api/`, reusing the existing client rather than a second fetch layer
 - [ ] 1.2 Drive them through `submitRule`/`pollRuleStatus`, so polling and the terminal `failed`/`unsupported` states are the same code an ordinary generation uses
+- [ ] 1.2a Make that reuse possible first: `submitRule` and `pollRuleStatus` are hardcoded to the rule-family endpoints and take a required `token` that `createApiClient` turns into an `Authorization` header unconditionally. Parameterize the endpoint and make the token optional. **Not a divergence signal** — see D1; these were written when every caller was authenticated, and the demo is the first that is not
+- [ ] 1.2b Confirm an unauthenticated call sends no `Authorization` header at all, rather than one with an empty token. A header the service must then decide how to ignore is a worse contract than its absence
 - [ ] 1.3 Write through `writeRuleFile`. If the demo needs its own writer, stop: the shapes have diverged and that is the finding
 - [ ] 1.4 Report a terminal status by surfacing the service's reason, which `unsupportedMessage` already prefers over our own text
 - [ ] 1.5 Regenerate `src/generated/api.d.ts` once the endpoints are published