Shield Legal LLC (2026–present)
Principal Architect, UI/UX. The chapter that follows Cox Automotive — this is where the platform work lands in a new domain and a new team.
Status
In role since March 2026. The ADR is written and has been executed: the MVP UI was built to that exact specification and stack.
Current Mandate
Three interlocking tasks define the opening work:
1. ADR: UI Stack for an AI-Native Development Team
Authoring the Architecture Decision Record that defines the UI stack Shield Legal will build on. The stack under consideration:
| Layer | Choice |
|---|---|
| Framework | Next.js |
| UI library | React |
| Component library | shadcn/ui |
| Styling | Tailwind CSS |
| State management | Zustand + persist middleware |
| Agent integration | MCP tooling |
| AI assistant | Claude (under evaluation) |
| Interaction pattern | Action–State |
| React style | Functional components preferred |
| Data | Postgres, reached through the BFF |
The ADR isn't just a technology list — it's the architectural argument for why this stack is coherent for a team building AI-native products. The action-state pattern, independently validated across 4 reference apps with multi-framework ports (autos 7 / funnel 8 / tinker 8 / sudoku 10), is the centerpiece: it gives agents and humans the same contract for driving UI state.
2. Train & Mentor the Engineering Team on AI-Native UI Development
Bringing the team up to speed on what "AI-native" means in practice — not AI-assisted (LLMs writing code) but AI-integrated (agents driving interfaces through declared contracts). The action-state pattern is the primary vehicle: teach the pattern once, and both human developers and LLM agents can reason about any component built on it.
3. Ongoing Forum to Support the Training
A recurring forum to sustain the knowledge transfer — questions, worked examples, pattern review, and the kind of incremental calibration that can't happen in a single training session.
Why This Stack
The Cox Automotive chapter established web components as the composable primitive. Shield Legal's stack shifts to React + shadcn for a different reason: the team is already React-native, and shadcn's unstyled component model plays well with Tailwind in the same way Lit components did at Cox — the styling layer (Tailwind) is separate from the component layer, and both can be locked to design constraints without coupling.
Next.js supplies two things the stack would otherwise have to assemble piecemeal: routing, and a backend-for-frontend. The BFF role is the load-bearing one — it gives the UI a server boundary of its own, so the shaping of data for the interface lives next to the interface rather than in a service owned elsewhere. Routing comes along with it instead of arriving as a separate dependency and a separate set of conventions.
Zustand with persist replaces the event bus as the state primitive. The event bus (mitt.js) was the right choice for a micro-frontend topology where components need to communicate across framework boundaries without direct coupling. In a single-framework React app, Zustand gives the same decoupled state management with better DevTools, built-in middleware, and first-class React integration. The action-state pattern maps onto Zustand naturally: actions are Zustand store methods, state is the store's observable slice.
MCP tooling and Claude complete the AI-native picture: the declared action-state surface becomes the agent API. An LLM can inspect the store, invoke actions by name, and observe state transitions — the same inspectability that Proofs mode gave to the YAML platform, now applied to a production React stack.
The ADR as Executable Spec
The MVP UI was built from the ADR itself. The document was handed to Claude Code as markdown and the application was implemented against it — same stack, same interaction pattern, no drift from the specification.
This is the pattern from proto-specs and spec-cleanroom arriving in production work rather than in a benchmark. There, implementation-derivable SPEC.md documents were published deliberately so that independent agents could build from them with no access to a reference implementation. Here the ADR played the same role without having been written for that purpose: a document precise enough about stack, structure, and interaction contract that an agent could execute it directly.
It is also the declarative lineage closing on itself one more time. The spec is the ADR. The runtime is the agent. The author describes what the system should be, and something else handles execution — the same shape as a knowledge base and an inference engine in 1985, and a YAML spec and the Juris runtime in 2025.
In the MVP, the Next.js BFF talks to a Postgres database — so the server boundary the BFF was chosen for is doing real work: the UI owns the shaping of its own data, and the store stays behind that boundary.
What Will Go Here
- How the MVP held up past the first release — where the spec-built code needed hand correction, and where it didn't
- What the training uncovered about where the team was vs. where it needed to be
- How the forum evolved and what format worked
- Whether agent-driven interaction ships in the product itself, not just in how the product was built
- The chapter's eventual legacy — what it contributed to the 40-year arc