Dataworkers

Codex for efficient development

Repository design, durable tasks, visual proof and steering from anywhere.

Two repository shapes. Three practical demonstrations. One operating method.

Abstract software delivery system turning multiple inputs into one controlled output

Code is a step, not the system.

IdeaDecisionSpecificationTaskCodeTestsRendered resultReviewRelease

Implementation became faster. Architecture, visual quality, verification and release confidence did not solve themselves.

Research first. Framework later.

01
What must users do?

Start with the product behavior and the target device.

02
What must run elsewhere?

Data, authorization, integrations and background processing.

03
What must be previewed?

Rendering, deployed behavior, databases and external services.

04
What is costly to reverse?

Runtime, framework, database, identity and deployment topology.

Research the fieldCompare constraints, prior experience, and likely future use.
Grill the assumptionsQuestion-driven planning exposes requirements you have not stated yet.
Build for continuationAn intentional MVP can become the first production slice.

One method. Two repository shapes.

Small website
1main deployable
Few local workflowsDeno and content work
Fresh 2Server output with small interactive islands
Larger monorepo
Manyowned projects
Reusable workflowsArchitecture, deployment and testing
Several appsApplications and shared packages

Small product, small repository.

routes/Pages and API endpoints
components/Server-rendered UI
islands/Interactive browser leaves
content/Markdown articles
static/Public assets
Deno already supplies formatting, linting, type checking, tests and task execution.
Fresh application
import { App, staticFiles, trailingSlashes }
  from "fresh";

export const app = new App()
  .use(staticFiles())
  .use(trailingSlashes("never"))
  .fsRoutes();
Server component + island
import MobileMenu
  from "./MobileMenu.tsx";

export default function Header() {
  return <header>...<MobileMenu /></header>;
}

When the graph becomes architecture.

Applications compose and deploy

web appFramework entrypoints and composition
API serviceHTTP startup and dependencies
background workerBackground processing runtime
browser testsPlaywright acceptance

Packages own testable behavior

feature and UIComponents, feature logic and data access
API and domainRoutes, use cases and domain logic
shared coreContracts, configuration and shared rules
adaptersDatabase, storage and external services
app -> route -> feature -> data access

Nx is useful when it pays rent.

The graph earns its costUse Nx because dependencies and task orchestration are real product concerns.
OwnershipProjects and tags make responsibility queryable.
BoundariesDependency direction is checked instead of remembered.
Task executionTargets, caching and affected checks reduce repeated work.
GenerationNew packages begin with consistent structure and metadata.
One deployable with limited sharing does not need this graph.

The repository is the prompt you keep.

AGENTS.md

Rules and boundaries

Commands, architecture, safety and what the agent must not silently change.

Root guidance
Nearest app or package guidance
Skills

Reusable workflows

Focused instructions, references and scripts for recurring work.

Nx generation
Migrations
Deployment review
Content production
Sources

Project truth

Architecture, design, framework, product and business material.

DESIGN.md
Constitution
Official docs
Marketing guide

A long feature needs three artifacts.

spec.md

What must be true?

Users, scenarios, requirements, measurable outcomes and exclusions.

FR-004: Users can export a report as PDF.
→
plan.md

How will this repository deliver it?

Verified technology, ownership, interfaces, paths and validation.

Rendering -> UI package
Orchestration -> feature package
→
tasks.md

What happens next?

Stable IDs, exact paths, observable completion and executable checks.

[x] T014 Align report edges and rerun visual checks.
ExecPlan.md
A viable single-file alternativeOne living executable specification can combine context, technical decisions, milestones, progress, discoveries, and next steps. It follows the same paradigm and is a workflow I am currently testing.

Small tasks keep long work steerable.

[x] T014 [US2]

Align the report with the application shell.

Add an exact edge-alignment assertion.

Then pass:
  UI checks
  web build
  visual E2E
  architecture checks
  diff checks
01Choose the next task
02Implement one slice
03Run targeted checks
04Inspect the rendered result
05Correct or steer
06Record the evidence

Stable IDs survive multiple sessions, context compaction, handoffs and recovery.

Every repository gets a tested UI system.

shared UI

Build the foundation

Tokens, typography and reusable components belong to one project-owned layer.

→
/design-manual

Render the states that matter

The dedicated page grows whenever feature work produces a component worth keeping.

→
Playwright

Catch visual drift early

Fast E2E checks cover the page, responsive layout and screenshots of interactive states.

Small websiteDesign Manual for shared UI Larger productDesign Manual plus focused screenshot tests

Green code is not a finished product.

01Automated checksTypes, tests, contracts, architecture, migrations and builds.
02Agent browser inspectionConsole errors, DOM state, flows, loading behavior and responsive geometry.
03Human device inspectionHierarchy, readability, touch behavior, visual quality and whether the experience feels correct.

Tests prove known behavior. They do not prove that the rendered product looks right.

Use the cheapest preview that answers the question.

Local tunnel

Does this task look right?

  • Seconds to inspect
  • HMR and rapid steering
  • Current worktree
  • Applications, decks and documents
preview.example.com -> localhost

Pull request preview

Does the deployed feature work correctly?

  • Production-like build
  • Stable review checkpoint
  • Environment integration
  • Preview database and authentication
PR -> deploy -> verify -> merge

Your phone is for steering, not coding.

ChooseSelect the repository, worktree and bounded task.
WatchReview progress, approvals and the agent's evidence.
InspectOpen the local or PR preview on the target device.
CorrectAttach a screenshot or give a precise visual instruction.

Application UI, HTML presentations, PDFs, documents, reports and dashboards.

390 × 844
Task selected Preview ready Feedback attached Correction queued
Dataworkers

Six rules to take home.

Choose technology from the problem.

Use the smallest honest repository shape.

Encode durable constraints in AGENTS.md.

Turn repeated work into skills.

Break large features into verifiable tasks.

Combine checks, browser inspection and human review.

The agent can write the implementation. Your leverage comes from keeping the work understandable, verifiable and steerable.