01
Business context
Loading
04 / Workflow orchestration
AI Content Automation / Engineering experience
Follow a structured brief through safety checks, instruction assembly, schema-backed generation, persisted review, deterministic exports, and Google Docs delivery preparation.
Code and architecture case study — live deployment currently unavailable.
Provider-backed generation and Google Docs delivery require separate configuration and are not represented as verified live outcomes.
01 / 08
Workflow intake
The repository begins with a typed, workspace-scoped content brief—not a blank chat box. That contract gives every downstream service explicit context.
Workspace access is checked server-side. Submitted fields are validated, normalized, and saved with a snapshot before a run can use them.
ContentBrief · BriefStatus · WorkspaceMembership
Business context
Editorial direction
Operating goal
Persistence
02 / 08
Orchestration canvas + transformation inspector
Select all eight stations to inspect inputs, work, outputs, failure conditions, ownership, and repository evidence. Then inspect sanitized representative data without triggering a provider request.
Orchestration canvas
Repository-backed workflow · no live provider calls
Select a station to inspect its contract
Transformation inspector
Each view is sanitized and representative of repository contracts or opt-in seed data.
Representative synthetic data derived from the opt-in repository seed.
{
"businessName": "North Star Media",
"audience": "Seed to Series B SaaS marketers",
"brandVoice": "Strategic, grounded, concise, operator-first",
"platforms": [
"LinkedIn",
"X",
"Email"
],
"goals": [
"Book discovery calls",
"Grow warm pipeline"
]
}03 / 08
Review boundary
Inspect which decisions can be automatic, which require judgment, which block progress, and which approval state is a recommended production extension rather than current persistence.
04 / 08
Google Docs delivery architecture
The repository implements authorization, document preparation, Docs and Drive API work, and failure recording. This walkthrough explains that code boundary; it does not simulate a successful live delivery.
Verification boundary: delivery services and automated tests are present in the public repository. OAuth consent, provider credentials, folder permissions, and a successful external document write still require separate live-environment verification.
05 / 08
Execution history + recovery
These clearly labeled synthetic runs show the states supported by the schema and realistic failure points. There are no timers, live traffic, or claimed automatic retries.
Representative execution history
Synthetic records · static · no live traffic
06 / 08
Engineering decisions
Each choice below is tied to repository evidence, its accepted tradeoff, and an operational consequence.
StructuredOutput is independent from RunDelivery.
Responses API parsing uses generationOutputSchema.
Proposal and acceptance are separate server actions.
USER_OAUTH and SERVICE_ACCOUNT metadata are supported.
generateRunAction awaits the provider call directly.
07 / 08
Technology evidence
Every technology below owns an observable application responsibility in the public repository.
App Router interface, protected layouts, server actions, and route handlers.
package.json · app/
Workspace tenancy, briefs, run status, structured output, security events, and delivery records.
prisma/schema.prisma
Server-only schema-backed campaign-plan generation and section refinement.
lib/ai/
Contracts at form, generation, refinement, authentication, and integration boundaries.
lib/validations/
OAuth, Drive-folder validation, Docs creation, content insertion, and delivery metadata.
lib/google-docs/
Coverage across auth, tenancy, generation actions, exports, refinement, OAuth, and delivery services.
tests/
08 / 08
Deployment reality + reflection
This project demonstrates coordination across tenancy, provider contracts, persistence, review, export, and delivery. Dependable live operation still requires durable background work and verified external configuration.
Before a live release, I would move generation into a durable worker, add explicit approval records, verify OAuth reconnect and revoke behavior, configure transactional email, exercise provider failure paths against disposable infrastructure, and establish operational monitoring.
Honest limitations
Current status
The repository proves the application boundaries. A live environment must still prove the providers, persistence, authentication email, and operating model together.