Document the date context in check_availability

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-31 15:46:40 +02:00
parent de7725bfb2
commit d11ca36764
1 changed files with 38 additions and 0 deletions
@@ -173,6 +173,44 @@ scanned 110 of 110, complete
 escalate: true
 ```
 ### It answers with a date
 The other half of what filtering unlocked. `check_availability` now consults
 the sales domain too: `list-order-details` filtered by product **and**
 status (`In Process`, `On Hold`) — `Orderdetail` carries the order's
 `requireddate` and `order_status` denormalised on the line itself, so this is
 one call per status, not one per order.
 ```
 "Peut-on promettre S18_1749 ?"
  → "Yes … 2720 in stock, above the reorder threshold of 50. Basis: stock on
     hand, already net of order lines placed through the API. 2 open order(s)
     already commit to this reference; the nearest is due 2005-05-04
     (order 10407, On Hold)."
 ```
 This is **not** the deduction that turned out to be wrong two sessions ago —
 that would have subtracted these quantities from stock a second time. This is
 additive context only: what already-open orders expect, and by when. Silent
 when there is none; never blocks the answer if the sales domain cannot be
 reached.
 ### Two token exchanges, on purpose
 Catalog and sales are different audiences, so this workflow now holds two
 narrow tokens rather than widening the one it already had — the same reason
 every agent in this estate exchanges per callee rather than requesting a
 broad token once.
 ### A straight chain, not two branches joining
 The obvious shape was two parallel paths — catalog and sales — converging on
 `Answer`. Not built that way: whether a node with two incoming connections
 waits for both before running is exactly the kind of thing worth being certain
 of rather than assuming, and this endpoint answers rarely enough that a few
 hundred extra milliseconds from running sequentially is free. One straight
 chain, ten nodes, nothing to get wrong about ordering.
 ### It acts under its own machine identity
 `client_credentials`, not a mandate. An agent running on its own account acts