Check whether the outcome improved
Exercise the documented boundary
Import values below, at, and above the field limit using the relevant character representations. Record the intended measurement unit and compare acceptance with that rule. Include a short control and any normalization-sensitive example that exposed the defect so the correction does not create a different boundary after whitespace or encoding changes.
Compare preview and final text
Confirm preview validation matches the rule used during execution. Reopen accepted values and compare their complete content with the fixture, distinguishing visual ellipses from stored cuts. Check the beginning and end as well as length, since equal-length output can still contain an unintended replacement or normalization of the source text.
Check rejected-value recovery
Follow the reported location for an over-limit value and inspect the stated limit and unit. Correct only the intended field through the supported flow and retry. Confirm the message does not suggest changing a whole-file limit or discarding content when the actual issue is a field-specific representation or inconsistent measurement rule.
What to carry forward
Accept when the boundary matrix follows the documented unit, accepted text remains intact, and rejected values have usable correction guidance. Record untested field types separately. A parser or preview pass remains incomplete if the destination constraint, full stored text, or actual retry path has not been compared with the same fixtures.
Technical background: PostgreSQL documentation.
Keep the decision with the work.
Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.
Create an account See the product workflow