The Mana chat that rewrote the credit desk's rules

Evidence

What Mana caught, and what the desk does now

Mana caught	The desk now
Two customer records for one business (C-1007 and C-1011), each with a $10,000 limit: $20,000 of credit in two pieces, each inside the analyst's authority	Treats records that share an EIN, or a name plus an address, phone or email, as one business, and tests their combined balance against the lower limit (REL-1, SOD-5)
Application answers, emails and remittance notes are read by an AI agent, so a fraudster can write instructions into them	Treats text from applicants and customers as evidence, never an instruction. Text that tries to direct the desk is a fraud stop (GEN-3)
No defined fraud referral path	Stops every shipment on a fraud hold, cash in advance included, sends the controller every hit with its CRS request id, and never tells the applicant which check failed (FRR-1 to FRR-7)
Orders could stack past a limit, and uncleared checks could release them	Counts released orders and the new order in exposure, and counts only cleared payments (ORD-2, ORD-3)
No rules for disputes or early reviews	Stops dunning on a disputed amount but still counts it toward the limit; reviews risky accounts and limits above $25,000 every 6 months (DSP-1 to DSP-7, REV-2, REV-3)

The pushback, before adopting anything

The 69 proposals were checked against the test case first. Six problems went back to Mana: BND-5 would have moved APP-1045 from band B to C; BIZ-3 needed to know who filed each UCC lien, and the business file only counts them; HLD-1 quietly let the clerk release holds that ORD-1 reserves for the controller; GEN-2 would have treated "no file at this bureau" as a failed check; FRD-7 would have flagged a customer's known second shop; LIM-3 and FRD-9 needed data the case does not have. Mana fixed or deferred each one, cut the list to 35, and named six rules that could still change an outcome depending on fields it had not seen. The third turn sent those fields; none of the six fire.

Checked again in the repo

All 67 rule ids load with the desk's own loader, the draft's 32 rule texts are unchanged, and every rule id mentioned inside a rule exists. None of the 35 changes a decision in the answer key.

The rules in use

Under the 0.2 rules, live Droid runs cite the new rules: FRR-1 and FRR-2 on the fraud referral, REL-1 and SOD-5 on the duplicate customer, COL-10 on the misapplied payment, COL-8 on the post-dated check, ORD-2 on order releases, LIM-4 and TRM-1 on every credit decision. The latest of them, run 73c47b, caught 14 of 14 planted errors with 0 false alarms.

The status route, on every merge

From the Oct 24 merge-gate run on the x86 test VM:

track mana
  ok    GET /t/mana/status lists the waiting task and its question
  ok    the public status carries no prompt
  ok    after the OK it shows the task done

How it works

1. YouThe draft rules go to ManaThe company profile and 32 rules, with four areas to probe.
2. OutsideMana reviews12 gaps ranked by risk, 69 proposed rules as YAML, parsed and checked for id clashes.
3. YouChecked against the test caseSix problems go back, with the 12 decisions the case must reach.
4. OutsideMana cuts to 35Checks all 12 outcomes, lists what it deferred and why, writes the changelog.
5. GurtOS coreRules 0.2 load into the desk's toolsAll 67 ids load; the tools refuse any rule id the file does not have.
6. TaskThe seats cite the new rulesFRR-1, FRR-2, REL-1, SOD-5, COL-10, COL-8, ORD-2 in live Droid runs.

Task

its own Linux user, its own copy of the files, no keys

GurtOS core

the GurtOS service on the box, root, the only part that reads the vault

Outside

a service outside the box

You

a person, on the portal, a phone, Jira or a chat

The GurtOS status app. Mana's agent built it from a one-message spec, made it public, and tested it signed out at phone size, with sample data and with a dropped connection. It runs in the viewer's browser and calls the box every 5 seconds. Until the box answers, it says "The box isn't reachable right now"; it never shows sample data.

It reads GET /t/mana/status, a route the Mana track adds to the box:

• Public on purpose, so it holds little. Task id, title, state, the latest step (cut to 160 characters), cost, source and time; the question and amount of each approval that is waiting; counts by state; the total cost.
• Read-only. One GET route. Approving still needs the portal or a paired phone.
• CORS open (Access-Control-Allow-Origin: *), so the Mana page can fetch it.

Try it

1. Open the planning chat and compare it with the header and rules of credit-rules.yaml.
2. Open the GurtOS status app on your phone.
3. On your own box, the route is on by default: curl -s localhost:7700/t/mana/status. To show it to a Mana app, forward only that path through your web server, for example with Caddy:

handle /t/mana/status {
	reverse_proxy 127.0.0.1:7700
}

Live, test and simulated

Part	State	Details
The planning chat and project page	Live	Public Mana pages. The chat is a snapshot taken after the third turn.
GurtOS status app	Live	Hosted in Mana. It reads a public, read-only status route on the always-on GurtOS box on Vultr. The box's web server forwards only that route and the Jira routes; the rest of its API is not reachable from the internet.
What the status app shows	Live	Task id, title, state, latest step, cost and time, and the question of each waiting approval. No prompts, tool calls, log lines or secrets.
The merge gate's check	Simulated	./demo checks the status route on a throwaway box, not the Vultr box.

Limits

• The status app is read-only by design. A judge watches tasks in Mana but approves on the portal or phone.
• The chat is a snapshot: Mana shares a chat as it was when it was shared.
• The project page was written before the OS was named GurtOS, so it says "the box".