The visible feature was only the surface
A build can succeed locally yet fail on Netlify because base paths, publish directories, runtime models, redirects, adapters, or environment requirements are misidentified.
The system also had to respect concrete constraints. Static, SPA, hybrid, and SSR routing require different contracts. Netlify adapter behavior is framework/version-sensitive. Dashboard/environment/deployment changes are remote actions that need explicit authority.
My role covered agent workflow design and automation engineering, with responsibility for agent workflow, validation automation, and packaging.
I turned the constraints into boundaries
Project/framework/lockfile detection; deterministic netlify.toml and output audit using documented patterns; local build/route verification and authorization-gated remote handoff.
Derive an explicit build contract before changing configuration.
Prefer maintained framework adapters over hand-written function shims.
Preserve unrelated configuration and never hide build defects behind catch-all redirects.
The key decision: Derive an explicit build contract before changing configuration.
The implementation had to prove the model
I delivered the work across the full path: Implemented package manager/framework/runtime detection. Built a Python Netlify configuration auditor. Codified redirect, base, publish, functions, and adapter rules. Added installer and package verification.
The result is concrete: Agents can classify a project's runtime model. Repair minimal local configuration. Verify root/nested routes and output shape. Separate a deployment-ready local state from unperformed dashboard/deploy actions.
The senior engineering lesson was that solving the visible workflow is only half the job. The architecture must also make constraints, failure modes, evidence, and ownership explicit enough for the next change to remain safe.
