RomanNum3ral
/
gstack
mirror of https://github.com/garrytan/gstack.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

feat(plan-eng-review): flag optimistic-UI on a server-gated action as a code-quality check 

Adds one Code-quality-review bullet: for an action whose real effect is gated or
actuated server-side (auth/permission/validation), check that the client awaits and
surfaces the real result rather than optimistically assuming success. Optimistic
status + a swallowed rejection renders as a false success — a green check while the
server quietly rejected and nothing happened.

The catalog already has general "silent failure / swallowed error" framing in the
adversarial /ship pass; this names the specific, common client↔server variant so an
eng-review reviewer checks the effect landed, not the toast. Source edited in the
section template; generated section doc regenerated via `bun run gen:skill-docs`.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Tim Linnet 2026-06-04 19:55:14 -07:00
parent cab774cced
commit 20ae32aec5
2 changed files with 2 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
plan-eng-review/sections/review-sections.md
View File

@ -126,6 +126,7 @@ Evaluate:
* Code organization and module structure.
* DRY violations—be aggressive here.
* Error handling patterns and missing edge cases (call these out explicitly).
* Server-gated or actuated actions with optimistic UI—does the client await and surface the real result, or assume success? A swallowed rejection (auth/permission/validation) renders as false success; verify the effect landed, not the toast.
* Technical debt hotspots.
* Areas that are over-engineered or under-engineered relative to my preferences.
* Existing ASCII diagrams in touched files — are they still accurate after this change?

1
plan-eng-review/sections/review-sections.md.tmpl
View File

@ -28,6 +28,7 @@ Evaluate:
* Code organization and module structure.
* DRY violations—be aggressive here.
* Error handling patterns and missing edge cases (call these out explicitly).
* Server-gated or actuated actions with optimistic UI—does the client await and surface the real result, or assume success? A swallowed rejection (auth/permission/validation) renders as false success; verify the effect landed, not the toast.
* Technical debt hotspots.
* Areas that are over-engineered or under-engineered relative to my preferences.
* Existing ASCII diagrams in touched files — are they still accurate after this change?