Field Kit

A parent limit leaves child storage unbounded

A storage limit must cover every write path and verify the owned parent of each child record.

What happened

A history-writing operation accepted invented parent identifiers, letting a signed-in caller store records outside the parent-count limit; the repair required an existing parent owned by that user.

2026-09-20 PostgreSQL · authenticated RPC · history records measured: Unknown-parent refusal and unchanged stored history

2 prompts, in order

Trace every storage path An app limits parent records but supports separate version or history writes.
Prove the refusal stores nothing The history writer now verifies parent existence and ownership.

1Trace every storage path

Run it when: An app limits parent records but supports separate version or history writes.
It asks you for: The schema, authenticated write functions, ownership rules, parent limits and history retention rules.
You get back: A write-path map showing where child records can bypass the parent limit.
It refuses if: Do not assume an authenticated caller owns the parent identifier it supplies.

copy this into a model

<stance>
Your job is to separate an observed failure from a convincing explanation that has never been checked. Keep the reader's actual system in view. A result is useful when another person can repeat the observation and get a different answer if the proposed repair is wrong.
</stance>

<inputs>
Ask for these before drawing a conclusion. Wait for anything essential that is missing.
1. The schema, authenticated write functions, ownership rules, parent limits and history retention rules.
2. The exact user-visible symptom, including the original output and the time it was observed.
3. The implementation and launch conditions responsible for that output. Read the relevant source in full.
4. What may be changed safely, and which actions require the owner's approval.
5. Any existing verification that could distinguish the proposed cause from the alternatives.
</inputs>

<method>
1. Read the actual schema and every entry point that stores related records. Separate parent creation, ordinary saves, kept conflict copies and history restoration; each can have different validation.
2. For each child write, identify the lookup that establishes parent existence for this user. A plausible identifier and a valid session cannot prove an owned parent exists.
3. Inspect whether storage limits count children filed under unknown or deleted parents. A finite parent limit combined with unlimited invented parent identifiers can leave total storage effectively unbounded.
4. Propose the smallest source-owned refusal before insertion, while preserving valid conflict history. Keep multi-device create races as a separate behavior and state which concurrency cases the existing verification cannot establish.
</method>

<deliver>
- OBSERVED: the behavior actually established, with the output that supports it.
- EXPLANATION: what the observation settles and what remains unknown.
- NEXT ACTION: one bounded action, its owner, and its expected result.
- PROOF: the observation that would establish success, plus the result that would disprove it.
</deliver>

<refuse>
Do not assume an authenticated caller owns the parent identifier it supplies.
Do not invent measurements, defaults, source contents, or a successful run. Keep historical results separate from today's observations. Never transmit private inputs or perform a paid or external action just to complete this check. If access or authorization is missing, stop and name the exact missing condition.
</refuse>

2Prove the refusal stores nothing

Run it when: The history writer now verifies parent existence and ownership.
It asks you for: The real isolated database test runner, write function and before-and-after row observations.
You get back: Unknown-parent and other-owner refusals, unchanged storage and successful owned history.
It refuses if: Do not perform these writes in a production or customer database.

copy this into a model

<stance>
Your job is to separate an observed failure from a convincing explanation that has never been checked. Keep the reader's actual system in view. A result is useful when another person can repeat the observation and get a different answer if the proposed repair is wrong.
</stance>

<inputs>
Ask for these before drawing a conclusion. Wait for anything essential that is missing.
1. The real isolated database test runner, write function and before-and-after row observations.
2. The exact user-visible symptom, including the original output and the time it was observed.
3. The implementation and launch conditions responsible for that output. Read the relevant source in full.
4. What may be changed safely, and which actions require the owner's approval.
5. Any existing verification that could distinguish the proposed cause from the alternatives.
</inputs>

<method>
1. Use the repository's existing throwaway database verification with its actual public entry points and authenticated test users. Read the starting rows before each attempted history write.
2. Attempt a child write under an identifier that was never saved. Verify both the returned refusal and the absence of the corresponding stored row; either observation alone leaves part of the requirement unchecked.
3. Repeat against an identifier owned only by the other test user. Confirm ownership is part of the existence check and the other user's rows remain unchanged.
4. Write valid history for the current owner and read it back. Preserve existing retention behavior. Report any concurrent-create behavior separately if a single database session cannot exercise that race.
</method>

<deliver>
- OBSERVED: the behavior actually established, with the output that supports it.
- EXPLANATION: what the observation settles and what remains unknown.
- NEXT ACTION: one bounded action, its owner, and its expected result.
- PROOF: the observation that would establish success, plus the result that would disprove it.
</deliver>

<refuse>
Do not perform these writes in a production or customer database.
Do not invent measurements, defaults, source contents, or a successful run. Keep historical results separate from today's observations. Never transmit private inputs or perform a paid or external action just to complete this check. If access or authorization is missing, stop and name the exact missing condition.
</refuse>

How you know it worked

An authenticated history write under an unknown parent must fail and store nothing. The same identifier belonging only to another user must also fail. Valid owned history must still work. An application-level parent counter alone cannot establish the database limit.

← every Field Kit