Add acumatica-silent-success-traps skill to the DEV plugin

[saratcvemuri]

Implements the skill accepted in #4.

What this adds

A skill for the class of Acumatica API behaviors that return success and do nothing, or return empty instead of an error. There is no exception to catch and no error code to branch on, so an integration reports success to its caller and an agent reports a confident wrong answer.

The rule it teaches: a 2xx is not evidence of effect, and an empty result is not evidence of absence. Five instances, each independently reproduced:

1. A write discarded because the principal lacks edit rights on the target form — HTTP 200, nothing persisted.
2. A write discarded because the field is not settable through the endpoint — identical 200, different cause.
3. A body-less 200, which is not the same as {"value":[]} and means the query never ran.
4. A $filter referencing a calculated column — documented as unsupported, but reported as an empty-body 200 rather than a 400.
5. A parameterized Generic Inquiry queried by its base name — 0 rows, 200, no error, because parameters bind only through the separate _WithParameters FunctionImport.

Plus one that surfaced while drafting: an inquiry whose name contains a URL path separator is accepted by Expose via OData and appears in $metadata, but 404s and never reaches the service document — it reports as published and simply never works.

Scope boundary

Deliberately separated from acumatica-integration-diagnostics: this fires when writing or reviewing code that issues these calls, not when repairing legacy integration clients. The description states that boundary explicitly so both skills do not load for one request. Happy to merge it into the existing skill instead if you would prefer that — the proposal offered either.

Version scoping

Behaviors were observed on Acumatica 2025 R2 SaaS. The skill scopes them once, beside the rule, and states that none of them is documented as a contract — which is why the scope is there rather than being boilerplate. Per the proposal thread, minimal verification against 2026 R1 is expected on the maintainer side; happy to adjust the wording to whatever you confirm.

Included

• DEV/skills/acumatica-silent-success-traps/SKILL.md — canonical skill, 87 lines / 795 words, no references/ or scripts/ needed
• DEV/skills/acumatica-silent-success-traps/agents/openai.yaml — Codex interface
• .github/skills/acumatica-silent-success-traps/SKILL.md — GitHub Copilot discovery adapter
• DEV/README.md — registration
• Verification/acumatica-silent-success-traps-review.md — no open P1 or P2 findings; three P2 items were found and fixed before submission, three P3 items are recorded, one left open deliberately (the imperative-voice description matches all three sibling skills, so changing it would make this one the outlier)
• DEV plugin manifests bumped 1.0.2 → 1.1.0 on all three platforms for the added skill

Verification run locally

.github/scripts/validate-contribution.ps1 -BaseSha upstream/2026R1 → passed (6 skills, 6 Copilot adapters, 2 plugins). The skill was also reviewed with this repository's own Common/agent-tooling/skills/verifying-skills, which is where the six findings above come from.

No customer data: a scan for instance hostnames, branch and warehouse codes, inquiry names, and document numbers returns clean. All content is original, contributed under GPL-3.0-only with DCO sign-off.

🤖 Generated with Claude Code

[k-s-popova]

@saratcvemuri , as per comment from @dnaumov here: #4 (comment), this is no longer the case for 2026 R1

[k-s-popova]

The statement that all behaviors were observed on 2025 R2 and that “none of them is documented” is inaccurate. Formula filtering restrictions and _WithParameters are documented.
Could you replace lines 21–24 (line 21) with per-trap applicability?

• REST write/read-back trap: confirmed for 2025 R2 and 2026 R1.
• Calculated-column restriction: documented.
• Body-less 200 response: observed behavior for 2025 R2 and 2026 R1.
• Parameterized GI behavior: _WithParameters is documented; the silent empty base-query result is observed.
• Path-separator issue: 2025 R2 only; fixed in 2026 R1.

[k-s-popova]

“Two causes discard a write” at line 29 (line 29) is too restrictive. The documentation already identifies graph logic as another reason a requested value may not persist. (See Documentation/IntegrationDevelopmentGuide/IntegrationDev_RESTExample_Basic_Update_Record.md (line 63) and the equivalent PATCH contract in Documentation/IntegrationDevelopmentGuide/IntegrationDev_RESTExample_Basic_Update_Particular_Fields.md .)
Consider to use “Known causes include” and add:

• Insufficient edit rights despite readable form access.
• Field not settable through the endpoint.
• Graph logic overriding or rejecting the requested value.
• PUT comparison behavior; PATCH may be appropriate when only specified fields should be updated.
  The invariant remains the same: independently read back the intended fields.

[k-s-popova]

Avoid claiming that the query “never ran”
A body-less 200 proves that the caller received no usable result; it does not necessarily prove that no database query executed.
Change lines 49–56 and 92 from “query never ran” to something like:
The response does not establish an empty result set. Treat the query outcome as indeterminate until it is retried or reformulated.

That preserves the safety behavior without asserting an unobservable implementation detail.

[k-s-popova]

The skill currently says “Acumatica API” broadly, but it mixes:

• Contract-based REST writes.
• Generic Inquiry–based OData reads.
  Name the applicable API surface in each section. This prevents agents from applying {"value":[]} semantics to contract-based REST responses or GI OData rules to endpoint entities.