06 · Development · One document end to end
One person finishes the path; there is still only one rule
The full-stack engineer, in a small scope, walks the same document through screen, API, and data, without dropping the transaction and permission floor. While the boundary is still in dispute, he does not ship “it can be tapped” and freeze the argument.
- Align the rule first: states, rejects, and idempotency live in one place. Screen and API both reference it.
- Then the screen: the error reason is visible. Submit cannot be double-tapped.
- Then the data: failure rolls back. A duplicate request does not create a second posting.
- Hand to test with replay steps for this document, not only a URL.
Full-stack shortens the handoff. It does not lower the bar
For a small module or a document that needs a fast proof, the full-stack engineer can change the screen, the service, and the table together. The value is that one document’s context is not understood three times by three people. The risk is he alone decides to put validation on the page. DaXi Technology therefore requires full-stack to keep the same floor as split frontend and backend: stock follows the server transaction; permission is checked again on the server; external calls do not go inside the local transaction. One fewer person is not fewer of these.
He fits documents whose boundary is already clear and whose wording is already frozen. If the boundary is still in dispute, a full-stack “it can be tapped” freezes the argument into code. Then the work should go back to architecture and product, not keep putting switches on the page. He also splits his work into reviewable commits: reject conditions first, then the success path. One commit that mixes style, a stock formula, and permission cannot get sign-off from the tech lead.
How full-stack does not become a private system no one can take
Code, migration scripts, config, and run notes must be takeable by a specialist. Critical logic may not live only in his notebook or local environment variables. The API contract is written down. Even if frontend is temporarily himself, next week a replacement does not have to guess. Database changes go through scripts. Columns are not hand-edited in production. This looks like process. It is the professional mark of the full-stack role: because no one naturally reviews your other half, you must leave the review in the repository.
Order cutoff from the button through to lock
Store ordering cutoff once had no owner. Frontend and backend each waited for the other to define the fields. The full-stack engineer finished the path from the requirements table: after cutoff time, the state locks, qty cannot change, a duplicate submit returns the first result. On the page the submit button appears only in to-submit. The server still checks state, so a direct API call is blocked. The steps he handed to test include: submit on time, submit after cutoff is rejected, duplicate submit, and cancel before the factory accepts. All four must replay before the module is handed over. How variance is closed, and how night shift over-receives, are not redone on this document.
When a specialist later took over, validation was not moved back onto the page. That shows full-stack delivered the same rule, not a demo only the author can run. In the handoff notes he wrote how to create one store, one next-day order, and the cutoff clock locally. An environment that cannot be created cannot be replayed by test. The script must build store, item, permission, and cutoff time from an empty database, then run the submit. A replacement runs this script first, sees the same reject, then changes code. Without this script, so-called full-stack delivery only hid frontend and backend complexity in one person’s computer. If the local database is missing a cutoff-time constraint, his machine will never reproduce the lock. Put the constraint in the migration script. Let the test environment fail first, not production.
While the boundary is still in dispute, he does not ship “it can be tapped.” If cutoff time is not signed and lock is already on the page, the argument freezes into code. Then it goes back to product and architecture. One commit does not mix style, the cutoff formula, and permission. Code, migration, config, and run notes must be takeable by a specialist. Critical logic may not live only in a notebook. The API contract is written down so next week a replacement does not guess. Stock transaction, permission re-check, and external calls not inside the local transaction: these floors are the same as when frontend and backend are split. One fewer person is not fewer of these.