feat(presentation): the companion's client for version 2 of the management pipe #55

2026-11-11T11:24:20Z

james.maes commented

2026-11-11 11:24:20 +00:00

Step 2 of the connection wizard build (ADR-0005): ManagementClient, the companion's client for version 2 of the management pipe. The window does not use it yet and no service answers version 2 yet, so nothing an operator sees changes.

What it is

One method for each of the 26 operations the companion sends; each takes plain values or the contract's own types and returns the contract's result record.
Every result says whether the request was certainly not sent, was refused by the service, or may have been carried out ("unconfirmed"), so a caller never repeats a state change by mistake.
At most twelve requests in flight. Three reads (snapshot, transport, job list) are skipped at that limit; everything else waits its turn.
One snapshot in flight at a time. A caller can ask for a snapshot that was sent after its call, for checks that follow a change.
A credential, password, enrollment code or token is passed on once and never kept, logged or put in a result or exception.

Decisions taken in review (recorded in ADR-0005, "Resolved while reviewing the management client")

A reply in the wrong version is not proof that nothing was carried out: for every operation that is not a read the result is unconfirmed and says to check before repeating. This reverses an earlier decision.
servers.add refuses a check that did not pass; servers.add and trust.set take the check the operator saw, not an address as text.
Addresses are passed as the origin the contract's address rule returned.
A reply that names another subject than the one asked about is unreadable.

Verification

Head fc21e42 on release/2.0 at 4c9b368.
build/Verify.ps1 passed on that head: 1,174 Core, 2,321 Windows runtime and command line, 749 presentation tests, none failed; presentation 100% of 1,621 lines, Core and command line 100%, Windows 96.08% (minimum 95).

Review (independent reviewers, four passes)

5bea411: 0 blockers, 2 should-fix, 9 nits (the version-mismatch decision; a snapshot that could be older than the caller's change).
e5c20ee: 0 blockers, 1 should-fix, 6 nits. The snapshot logic was stressed with 27,000 mixed calls: none answered from an earlier send, none skipped, never more than one snapshot at the pipe. The should-fix was three tests that depended on timing.
fc21e42, the head merged: Verdict on fc21e42: 0 blockers, 0 should-fix, 3 nits. Under the setting that made the three tests fail every time, the client's tests pass 16 of 16 and the whole suite 4 of 4; 260 of 260 parallel runs at the default setting.

Left open

Three nits from the last pass, for the next branch on this stack: one test name still says the client adds no rule of its own; "it answers requests of its own version that way" should say "some"; a wait in the test fakes that never ends fails without saying what it waited for.
One line has no test because none can reach it (IsCompletedSuccessfully in TakePlaceAsync); a comment at the line says why.
Two commits are typed test and change product code: a88f1db (a request that finds a place free returns with it at once) and 28c7620 (SingleFlight.Started gives the last flight, landed or not).

For the service step that builds the version 2 pipe server

No version 2 request may ever be answered outside the envelope; the client reads any non-JSON answer as an older service (recorded in docs/TODO.md).
Findings for the contract, not this change, and not yet in the audit (they go into the next documentation change): the golden reply of servers.reorder contradicts its golden request in order; ServersReorderArgs holds any text as an identifier; an empty enrollment code, printer, format or job could be refused where arguments are read.

Not proven here

Nothing ran against a service that speaks version 2; none exists yet.

🤖 Generated with Claude Code

Step 2 of the connection wizard build ([ADR-0005](docs/adr/0005-connection-wizard-and-server-tree.md)): `ManagementClient`, the companion's client for version 2 of the management pipe. The window does not use it yet and no service answers version 2 yet, so nothing an operator sees changes. **What it is** - One method for each of the 26 operations the companion sends; each takes plain values or the contract's own types and returns the contract's result record. - Every result says whether the request was certainly not sent, was refused by the service, or may have been carried out ("unconfirmed"), so a caller never repeats a state change by mistake. - At most twelve requests in flight. Three reads (snapshot, transport, job list) are skipped at that limit; everything else waits its turn. - One snapshot in flight at a time. A caller can ask for a snapshot that was sent after its call, for checks that follow a change. - A credential, password, enrollment code or token is passed on once and never kept, logged or put in a result or exception. **Decisions taken in review** (recorded in ADR-0005, "Resolved while reviewing the management client") - A reply in the wrong version is not proof that nothing was carried out: for every operation that is not a read the result is unconfirmed and says to check before repeating. This reverses an earlier decision. - `servers.add` refuses a check that did not pass; `servers.add` and `trust.set` take the check the operator saw, not an address as text. - Addresses are passed as the origin the contract's address rule returned. - A reply that names another subject than the one asked about is unreadable. **Verification** - Head `fc21e42` on `release/2.0` at `4c9b368`. - `build/Verify.ps1` passed on that head: 1,174 Core, 2,321 Windows runtime and command line, 749 presentation tests, none failed; presentation 100% of 1,621 lines, Core and command line 100%, Windows 96.08% (minimum 95). **Review (independent reviewers, four passes)** - `5bea411`: `0 blockers, 2 should-fix, 9 nits` (the version-mismatch decision; a snapshot that could be older than the caller's change). - `e5c20ee`: `0 blockers, 1 should-fix, 6 nits`. The snapshot logic was stressed with 27,000 mixed calls: none answered from an earlier send, none skipped, never more than one snapshot at the pipe. The should-fix was three tests that depended on timing. - `fc21e42`, the head merged: `Verdict on fc21e42: 0 blockers, 0 should-fix, 3 nits.` Under the setting that made the three tests fail every time, the client's tests pass 16 of 16 and the whole suite 4 of 4; 260 of 260 parallel runs at the default setting. **Left open** - Three nits from the last pass, for the next branch on this stack: one test name still says the client adds no rule of its own; "it answers requests of its own version that way" should say "some"; a wait in the test fakes that never ends fails without saying what it waited for. - One line has no test because none can reach it (`IsCompletedSuccessfully` in `TakePlaceAsync`); a comment at the line says why. - Two commits are typed `test` and change product code: `a88f1db` (a request that finds a place free returns with it at once) and `28c7620` (`SingleFlight.Started` gives the last flight, landed or not). **For the service step that builds the version 2 pipe server** - No version 2 request may ever be answered outside the envelope; the client reads any non-JSON answer as an older service (recorded in `docs/TODO.md`). - Findings for the contract, not this change, and not yet in the audit (they go into the next documentation change): the golden reply of `servers.reorder` contradicts its golden request in order; `ServersReorderArgs` holds any text as an identifier; an empty enrollment code, printer, format or job could be refused where arguments are read. **Not proven here** Nothing ran against a service that speaks version 2; none exists yet. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

james.maes added 16 commits 2026-11-11 11:24:20 +00:00

feat(presentation): the companion's client for version 2 of the management pipe 447497d742

ManagementClient is built beside ServiceClient, which is unchanged and keeps
speaking version 1 for the window until the views move. It takes the pipe's
"send one request, get the parsed reply" function and the log, and gives each
of the 26 operations the companion sends one method that takes plain values
and returns a ServiceResult holding the contract's own result record. No
request, reply or payload passes through a method in either direction, and
no constructor takes a server's name. servers.list, computer.getProfile,
update.prepare and update.resume are not the companion's to send; a test
lists them with the reasons and requires the two lists to cover the
contract's table.

Results:
- ServiceResult gains Code, the contract's error code of a refusal, and
  TryReadDetails, which reads the details only as the record the contract
  names for that code. A code this version does not know is a refusal that
  shows the service's message and carries internal_error.
- ServiceFailure gains OlderService (the reply was not JSON or had no
  version: a version 1 service answered) and NewerService (another
  version). Neither is unconfirmed: a service that does not speak this
  version carried nothing out. A reply of this version that cannot be read,
  and a result that does not fit its record, are unconfirmed.
- ServiceOutcome gains Skipped, for a read that was not sent because the
  ceiling was reached.
- A value the contract refuses when a request is built (a name that breaks
  the name rule, text that is no origin or no server identifier) is not
  sent and is answered invalid_request, as the service would answer it.

The provider's origin of servers.add and trust.set is an argument without a
default, so no caller can leave it out. It is sent exactly as given, and
null leaves the member out, which states that the check named no provider.

Limits: at most twelve requests in flight, counted until the pipe is done
with a request and not until its caller stops waiting. Over that, the three
reads the window repeats on a timer (snapshot, transport.get, jobs.query)
are skipped and every other request waits its turn, in order; one whose
caller leaves while it waits is never sent. snapshot and transport.get are
single-flight: a caller that asks while one is in flight shares its result.

Logging uses message templates and hands the log plain values only: the
operation, the server's identifier, the kind of failure and, for a failure
of the pipe itself, the pipe's own description. Nothing from a request's
arguments or from a reply's content is written; a test calls every
operation with marked values through every way a request can end and finds
the mark in no entry.

The tests use a scripted pipe (FakePipe, Replies) and the contract's golden
files, which the presentation tests link from the Windows layer's suite.
Every request the client sends equals its golden file once the file's
indentation is removed, which is the one line the wire carries.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

feat(presentation): the provider a request states comes from the check the operator saw 3207b233ac

AddServerAsync and SetTrustAsync took the sign-in provider's origin as
text. The argument states which provider the operator accepted, so it has
to come from the check the operator saw and from no other read of the
provider; text let a caller pass another read, such as the companion's own
read of the sign-in description, by mistake. Both now take the
ServerCheckResult the operator was shown, with no default, and the client
sends that result's provider origin exactly as the check reported it,
leaving the member out when the check named none. The wire is unchanged
and the golden requests still match.

- AddServerAsync refuses a missing check as a missing argument.
- SetTrustAsync refuses to switch the exception on without a check, as a
  missing argument, and sends nothing: without the check there is nothing
  the operator can have accepted. Switching it off accepts nothing and the
  contract compares nothing, so no check is needed there, the request
  states no provider, and a check given all the same is not used.

Documentation, as decided in review: each method says whether it is
skipped or waits its turn over the ceiling, and the reason an older
service's answer is not unconfirmed is marked as read from the version 1
handler and not run against one.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

fix(presentation): a refusal with an unknown code that repeats is a warning once 42b26cff7c

A refusal with a code this version does not know was a warning every time,
so a read refused with one on every tick would have written a warning each
second. The first such refusal of an operation on a server is a warning and
the same code repeating is a debug line, as a repeated failure is. Another
unknown code is a warning again, and so is the same one after the
operation was answered in any other way, by a result or by a refusal with
a code this version knows. What is remembered is the code as the log shows
it, never text of another kind that arrived where a code belongs.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

fix(presentation): the client refuses what the contract refuses and takes the contract's types 1aa7694600

Review of the management client (step2w-r1, N1, N4, N6 #13, N8).

Values the contract refuses are answered locally as invalid_request and
not sent, by the contract's own rules and no others. Before, that held
for three kinds of value only (a name, a provider's text, the envelope's
server text), and a null server identifier left as a request on the
computer.

- Every request is put to ManagementOperations.Check, so an operation
  on one server that names none is not sent (all sixteen methods).
- A request's arguments are read back with ManagementJson's own reader
  before they are sent, so a value the record needs and was not given
  (a credential, a code, a job, a profile, the list of servers, an item
  of that list) is not sent.
- What that reader accepts is sent; the client adds no rule of its own.

API shape, before more is built on it:

- CheckServerAsync and AddServerAsync take the origin ServerAddress.TryRead
  returned, not the typed text, and send it as scheme, host and port. An
  address that rule refuses is not sent.
- SetLogSettingsAsync takes the contract's record, LogsSetSettingsArgs.
- SignInAsync takes a SignInRepair, a type with the contract's two
  values and no way to make a third, where it took text.
- AddServerAsync refuses a check that failed, as an argument that is
  wrong: the operator goes on only from a check in which every stage
  passed. SetTrustAsync does not: a server whose own certificate is
  refused is the one an exception is for. Both methods say what the
  check argument's type does and does not guarantee.

A reply that names its subject is the answer only for that subject, as
jobs.details already was; any other is unreadable, so unconfirmed:
servers.rename's summary must be the server named, servers.add's the
address asked for (compared as origins), servers.reorder's list exactly
the servers given (the order is the service's to say). A job's
identifier is compared exactly, which a test now holds.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

fix(presentation): a version mismatch is not proof that nothing was carried out 96b3b29691

Review of the management client (step2w-r1, S1, N3, N6 #15 to #17, N9).
This reverses an earlier decision.

A reply that was not in this version of the pipe was reported as "an
older (or newer) service, nothing was carried out" on the form of the
reply alone. Text that is not JSON is what a version 1 service answers,
but it is also what any failure outside the envelope looks like, after
an operation may have acted; and a reply in another version need not be
the refusal of the version. For a test print, a retry, an add, an
enrollment or a sign-in the operator was told there was nothing to
check.

- OlderService and NewerService keep their values. For an operation the
  contract's table calls a read the result is still not unconfirmed. For
  every other operation it is unconfirmed, and its message names the
  side to update and says that the operation may have been carried out
  and must be checked before it is repeated.
- JSON without a version has no known sender (a version 1 service never
  answers in JSON): it is an unreadable reply, unconfirmed, and no
  longer OlderService.
- Text that is not JSON stays OlderService.

The send function's contract is stated where the client is given it:
which exceptions mean "certainly not sent", which mean "outcome
unknown", that nothing else may be thrown for what a pipe can do, and
that no exception message may hold request or reply text (the client
logs the description, at debug level with the stack, and shows the
message). A TimeoutException and an ObjectDisposedException from it are
now results with an unknown outcome instead of exceptions; any other
unexpected exception still escapes.

Documentation: for a refusal the code decides whether the service acted
(enrollment_unconfirmed and internal_error do not mean it did not);
ServiceFailure.Native no longer claims the request was not sent; a
result carries the service's text as it arrived.

Tests now hold three decisions that had none: text in upper case is not
logged as a code (a code is lower-case letters, digits and underscores),
a known code is matched exactly, and a failure that changes from sent to
not sent is a warning again.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

feat(presentation): a snapshot that is sent after the call, for a caller that checks a change 4617e0bbc2

Review of the management client (step2w-r1, S2, N2, N6 #50).

The snapshot had only the timer's behaviour: a call made while one was
in flight shared that one's result, and over the ceiling it was skipped.
A caller that reads the state to learn the outcome of a change (the
"check" after an add or an enrollment whose outcome is not known, a page
refreshed after a change) could be given a snapshot sent before the
change, or none, and offer a repeat of the change on it.

SnapshotAsync gains a parameter, sentAfterTheCall. The default is the
timer's behaviour, unchanged. With it set the answer is that of a
snapshot sent after the call was made and never an earlier one: the
call waits out a snapshot that is in flight and then sends another;
calls that wait together share that one; over the ceiling it waits its
turn and is not skipped; a token cancelled while it waits ends it with
nothing sent. It is still one method for the operation, and one
snapshot is at the pipe at a time.

SingleFlight counts its flights as they start, which is what lets a
caller ask for one that started after a moment it names. A flight is
now started only by a caller that holds a place under the ceiling, so
every flight was handed to the pipe and a skipped read is never one;
a caller that took a place and then found a flight to share gives the
place back.

A change whose turn comes at the very moment its caller leaves was sent
(4 of 3,000 rounds in review, each reported honestly as unconfirmed).
After the wait for a turn the client now looks at the token, gives the
place back and reports that nothing was sent, so "a change whose caller
leaves while it waits is never sent" holds. RequestCeiling's comment
described a cancelled task holding a place, which cannot happen.

A test now holds that a request which waited its turn goes on outside
the call that gave it the place, and so never under the ceiling's lock.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

test(presentation): a snapshot whose caller leaves as the one in flight lands has sent nothing 28c76201a5

A caller that asked for a snapshot sent after its call, and leaves at
the moment the snapshot in flight lands, is told that nothing was sent
for it, also when another caller has by then sent the next snapshot.
Without the check after the wait it would have gone on to share that
next snapshot and been told its request may have been carried out. No
test held that check; this one does, with the cancellation itself
landing the flight so the order of events is the test's.

SingleFlight.Started gives the last flight, in the air or landed,
instead of only one that is in the air: waiting for a landed flight is
over at once, so telling the two apart there decided nothing.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

docs(adr): record the two decisions from the review of the management client 0cbfe839d2

ADR-0005 gains "Resolved while reviewing the management client,
2026-11-11", with the two decisions the coordinator took on the
independent review:

- A version mismatch is not proof that nothing was carried out. An
  older or a newer service's answer to an operation that is not a read
  is reported as unconfirmed and says so; JSON without a version is an
  unreadable reply. This reverses what the client did.
- A snapshot can be asked for that is sent after the call, for a caller
  that reads the state to learn the outcome of a change; the timer's
  behaviour stays the default.

docs/TODO.md gains the constraint the first decision puts on the service
step that builds the version 2 pipe server: a test that no version 2
request is ever answered outside the envelope, because the client reads
any answer that is not JSON as an older service; and that step supplies
the send function, which has to keep the contract stated on the client.

The changelog entry for the client says "will be built on it", says what
changed in this round, and its logging paragraph now says that a pipe
failure's entry carries the exception's own description and, at debug
level, its full text with the stack, and why that is acceptable.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

test(presentation): the snapshot tests decide their own order of events under load a88f1db2d0

Two runs in about 240 of the client's tests failed while the machine was
busy, both in one new snapshot test and by its 30-second guard. It was the test and not the client:
when a flight lands, the callers that waited for it go on in no fixed
order (the first inline, the others on the pool), and the test asked
for a third snapshot while one of two callers that were to share the
second had not gone on yet. That caller then rightly shared the third,
which the test had not answered.

- The test of the reviewer's run no longer asks for a third snapshot.
Whichever of the two callers goes on first, there is one second
request and both get its answer, also when one goes on after it
landed. That a call made while a snapshot is in flight is not served
by it, even when that snapshot was itself asked for as "sent after the
call", moved to the test with one such caller, where the order is the
test's.
- The place-sharing test waits for the two answered requests before it
counts places.
- The address test sends its refused addresses through a pipe with
nothing scripted, so an address that is sent fails the test at once
instead of leaving it to wait for an answer.
- The two tests that cancel at an exact moment wait for the next request
to arrive instead of counting at once, so a runtime that orders the
events otherwise cannot fail them; and the caller that stays waits
with a token of its own, which is what makes it go on first.
- The test that a waiter goes on outside the call that gave it its place
delivers the answer on a thread it names. Delivered on the test's own
thread, the client goes on elsewhere and the test held nothing.

One product change: a request takes a place that is free without
looking at its token again. The look before it (in AskAsync) is then the
one that decides, as it was before this round; with both in place,
removing either one changed nothing, so neither was held by a test.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

test(presentation): a server's identifier in a reply is compared exactly 092ed4ff59

A rename answered with the server's identifier in upper case, and a
reorder answered with one, are replies for another subject: the contract
gives an identifier one spelling, and a job's identifier was already
compared that way. The comparison was exact; no test held it, so one
that ignored letter case passed.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

docs(presentation): say where the last look at a waiting caller's token is e5c20eec4f

A request that waited its turn looks at its caller's token once more
when the turn has come, and gives the place back when it is cancelled.
A cancellation that arrives after that look finds a request that is
being sent; it is reported as a wait that ended after sending,
unconfirmed. The comment said only the first half. Run again after this
round, the reviewer's race of 3,000 rounds had 2,999 requests not sent
and one sent and reported unconfirmed, none sent and reported as not
sent, and no place lost.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

test(presentation): three tests wait for what a failed request does afterwards 67ccac99f2

Three tests of the management client completed a held request and at
once asserted what the client had done with it: the entry for a failure
that arrives after its caller left (two tests, one of them with 26
cases), and the place a failed request gives back. The client goes on
inside the completing call only when the calling thread has no
synchronization context. xunit runs a test's first stretch under one,
and a test leaves it at its first await that has to wait. When the
cancellation these tests await had already finished, they never left
it, the client went on on another thread, and the assertion read the
state from before. The review saw it once in 240 runs under load; with
every test thread kept on a synchronization context these three failed
in every run.

- The log fakes can be waited on for an entry, as the pipe fake can for
  a request, and what they record is read and written under one lock:
  the late entry is written on another thread while the test reads.
  What they record keeps the members the suite uses (a count, an index,
  Clear, Exists), so no other test changes.
- The two tests of the late failure wait for its entry.
- The test of the place queues a change that waits its turn, fails the
  held request and waits for the change to arrive at the pipe.

No product change. Every wait is for an event, with a 30-second guard
that no test asserts on.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

test(presentation): the two orderings three tests rely on are tests of their own 31eb3f342e

Three tests of the client's limits bring about a moment they could not
otherwise reach (a caller that leaves at the instant its turn comes, or
the snapshot it waits out lands; a place given back while an answer is
still being delivered) through two things the runtime does: a
cancellation token runs its callbacks newest first, on a thread with no
synchronization context when the cancellation is awaited, and those
waiting for a task go on in the order they began, inside the call that
completes it. The three are written to pass on a runtime that orders
these otherwise, and there they would pass without testing what they
are named for.

Two tests now assert the orderings, waiting the way the client waits,
and a failure of either names the tests that lost their meaning.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

fix(presentation): a reorder's reply is compared with the servers as they were given 0d619d5534

ReorderServersAsync compared the reply with the caller's list as it was
when the reply arrived. A caller that reused or changed its list while
the request was in flight got "unreadable" for the answer to what it
had asked, and could get a reply for other servers read as its answer.
The list is now copied when the call is made; the copy is what is sent
and what the reply is compared with.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

test(presentation): three decisions of the client that no test held get one each ac2defe084

The review changed each of these and every test still passed:

- A snapshot asked for as "sent after the call" shares a later one that
  has already landed when its turn comes, and sends nothing. The test
  puts a change between two such calls, so the second's turn comes
  after the first's snapshot has landed.
- The address an add's reply names is compared as an origin. The test
  varies the reply's spelling (a trailing slash, upper case, the
  scheme's own port, all three); the existing one varied only what was
  asked.
- A reorder's reply names each server as often as it was given.

A fourth cannot be reached by a test: the client asks whether its wait
for a turn completed successfully, and not whether it completed,
because a wait that begins with a cancelled token is over at once as a
cancelled task. Only a cancellation between the caller's look at its
token and the wait gets the client there. A test of the ceiling itself
shows that such a wait is complete, cancelled and holds no place.

No product change.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

docs(presentation): two statements about the client made exact fc21e42517

- "A version 1 service never answers in JSON" is true of its answers to
  a version 2 request, which is what the client sends. It answers
  requests of its own version in JSON, a snapshot for one. Corrected in
  the client, in the comment on the reply parser and in ADR-0005.
- "The client adds no rule of its own" is not true of the check the
  operator saw: adding a server, and switching an exception on, are
  refused without it, and adding a server is refused with one that
  failed, though the contract's reader would accept each request. The
  changelog, ADR-0005 and two comments now say "one rule" and name it.
- A comment at the line says why the wait for a turn is asked whether
  it completed successfully, and that no test can reach the other case.

Comments and documents only.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

james.maes merged commit b86a971725 into release/2.0

2026-11-11 11:24:32 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: QRun-IO/qqq-print-agent#55