You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .agents/skills/charges/SKILL.md
+21Lines changed: 21 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -126,6 +126,8 @@ Current shared contract details:
126
126
- optional split outputs use pointers; `SplitGatheringLineResult.PostSplitAtLine` is `*billing.GatheringLine`
127
127
- use `billing.ValidateStandardLineIDsMatchExactly(...)` when a charge-side test or helper needs to assert that returned standard-line identities are preserved across a line-engine boundary
128
128
- collection-time errors should be normalized through `billing.NewLineEngineValidationError(...)` instead of rebuilding the validation-issue wrapper at each billing callsite
129
+
- charge line engines are only responsible for invoice-backed charge flows such as `credit_then_invoice`; they are not the execution path for `credit_only` settlement mode
130
+
- because of that boundary, it is acceptable for a charge line engine to return an error when invoked with `credit_only` settlement mode; treat that as a lifecycle misuse rather than adding `credit_only` behavior to the engine
129
131
130
132
## Timestamp Normalization
131
133
@@ -193,6 +195,25 @@ Placement guidance:
193
195
- do not mutate whole intents inside adapters just to normalize currency; if an adapter needs a persistence backstop, keep it local to the `Set*` write
194
196
- when ledger logic derives monetary values from balances, entries, or its own calculations, round those values in ledger code as well; do not rely only on upstream callers
195
197
198
+
## Zero Invoice Accrual
199
+
200
+
Invoice accrual uses a non-negative, no-op-aware contract.
201
+
202
+
Rules:
203
+
204
+
- negative invoice-accrual amounts are invalid
205
+
- zero invoice-accrual amounts are valid no-ops
206
+
- positive invoice-accrual amounts must produce a non-empty ledger transaction group reference
207
+
- charges-side services should short-circuit zero before calling persistence that expects a real ledger transaction
208
+
- do not persist `invoicedusage.AccruedUsage` rows with an empty `LedgerTransaction.TransactionGroupID`
209
+
210
+
Current expected behavior:
211
+
212
+
-`usagebased.OnInvoiceUsageAccruedInput.Validate()` allows zero and rejects only negatives
213
+
- usage-based and flat-fee service/orchestration layers should skip invoice-accrual persistence when the invoice line total is zero
214
+
- ledger handlers may still defensively tolerate zero and return `ledgertransaction.GroupReference{}`
215
+
- when a service proceeds with non-zero invoice accrual, it must require a non-empty transaction group reference before storing accrued usage
216
+
196
217
## Realization Helper Subpackages
197
218
198
219
Use small type-specific realization helper subpackages to keep charge services and state machines from becoming kitchen-sink orchestration layers.
0 commit comments