Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.tryhoard.com/llms.txt

Use this file to discover all available pages before exploring further.

Sometimes you ask for something and the assistant comes back with “I tried, but the server said no.” That’s good, it means the safety system caught something. But the message can be opaque the first time you see it. This page is the diagnostic tree. Find the error string the assistant reported, read the one-liner, apply the fix.

​
denied_by_grant

What it means. Your permission grant for that action kind is set to deny (or always_ask and you didn’t approve). The fix. Open Settings → Assistants → permission grants. Find the action namespace (e.g. pricing.edit_rule) and pick a less restrictive mode. If you genuinely want this blocked, leave it; tell the assistant to use a different approach.

​
floor_violation

What it means. One of the hard floors tripped. The assistant tried something the server invariant won’t allow. The error tells you which floor:
  • absolute_minimum, would have priced a card below $0.01. Not user-tunable. There is no fix; the request was nonsense.
  • per_rule_aggregate_drop, the single rule edit would have dropped your total listed inventory value by more than your cap (default 30%). Break the change into smaller steps, or raise the cap if you’re confident.
  • per_session_aggregate_drop, the cumulative drops in this 1-hour session exceed the cap (default 20%). Wait an hour for the rolling window to clear, or do the rest of the work from the dashboard.
The fix. Match the floor name to the description above. Most of the time the right move is “break it into smaller pieces” or “do this one from the dashboard.”
Hoard’s per-card floors (your hard_floor setting, never_go_down, change_cap_pct) are enforced silently as price clamps inside PricingAnalyzer before the engine ever decides whether to ship a price. You won’t see a floor_violation from those — the agent will see the clamped target instead. The three floors above are the ones that DO surface as floor_violation codes.
For details on each floor, see Agent permissions and safety → Layer 3: Hard floors.

​
rule_not_found

What it means. The assistant referred to a pricing rule by name or ID, and the server can’t find it. Usually it’s a slug typo, or the rule was deleted, or it expired. The fix. Ask the assistant to list your rules: “what pricing rules do I have active?”, then re-issue the edit using the exact name it reports.

​
invalid_multiplier / invalid_price_source

What it means. The assistant constructed a call with a value the server can’t parse. Multiplier outside the allowed range (e.g. negative, or above the hard ceiling). Price source not one of the known options. The fix. Tell the assistant the value you actually want in plain English (“set it to 1.25” not “set it to 1,250%”) and have it retry. If the retry produces the same error, the value you’re asking for genuinely isn’t allowed, pick a different one.

​
mutation_in_progress

What it means. Your account has a sync, rollback, or mass-reprice already running. Hoard serializes price mutations to keep your inventory consistent. Two of them can’t run at once. The fix. Wait. Ask the assistant “is a sync in progress?”, when the answer is no, retry. Most syncs finish in under a minute. If you’ve been waiting more than 10 minutes, check Settings → Sync for a stuck job and cancel it.

​
suggestion_cap_exceeded

What it means. You’ve hit the rate cap on draft plans the assistant can hold open against your account (currently 20 per rolling 24 hours). This stops a misbehaving assistant from spamming previews. The fix. Ask the assistant to drop its open drafts: “delete all your open plans, then retry.” Or wait, the oldest draft falls out of the window on a rolling basis. If you find yourself hitting this cap regularly, it usually means a permission mode is making the assistant generate many speculative previews; tighten the grant.

​
plan_expired

What it means. The preview Claude showed you is older than 5 minutes. Plans have a short TTL so the diff you approve matches reality at commit time. If you walked away for coffee, this is what you come back to. The fix. Ask the assistant to redo the preview. The numbers might shift slightly (if your inventory changed in the interim) but the flow is the same.

​
A worked example

You ask Claude: “drop my Lorcana commons rule to 0.5x.” Claude reports back: floor_violation: per_rule_aggregate_drop. What just happened: cutting that rule in half would have dropped your aggregate listed value by 35%, over the 30% cap. The server invariant caught it. Three legitimate responses:
  1. The cut was a bad idea. You misjudged the impact. Don’t retry.
  2. The cut is right but should be staged. Ask Claude to drop the rule to 0.7x first, sync, then 0.5x in a separate session next day. Each step stays under the cap.
  3. Your cap is wrong for you. You really do want to be able to halve a rule in one go. Open Settings → Pricing preferences and raise per_rule_aggregate_drop to 40%. Now the same call will go through.
The point: each floor exists because somebody would benefit from the limit. The right fix usually involves understanding which somebody you are.

​
When none of these match

If the error string the assistant reports isn’t on this list, two options:
  • Ask the assistant directly: “what does this error mean?”, modern assistants are pretty good at decoding their own error responses.
  • Check your activity log for the row, which will have a floor_violation or other field with more context.
If you’re truly stuck, screenshot the assistant’s response and email support. Include the timestamp so we can correlate against server logs.