ChartaFlow
Documentation, implementation guidance, and support knowledge with clear boundaries.
A tenant-aware documentation platform I direct and build with AI coding agents. It combines controlled publishing, API reference, customer-journey architecture, and grounded discovery with written constraints and repeatable verification.
Problem and role
Support teams need documentation they can maintain confidently and customers can find when something goes wrong. My experience supporting enterprise platforms shapes ChartaFlow’s focus on usable authoring, reliable publishing, and clear access boundaries.
I define requirements, scope agent tasks, review changes, investigate regressions, and verify releases. AI agents help implement the product; I guide the work and evaluate whether the result meets the intended behavior.
I designed an automated feedback flywheel around the code. Completed work and verified failures feed durable lessons back into product requirements, architecture, security boundaries, agent instructions, repository routing, and regression checks. Each agent starts from shared, current evidence instead of a one-off prompt or a manually refreshed briefing.
Current product capabilities
- Tenant-aware product foundation: projects are the content boundary, with invitations, fixed roles, and database-enforced access control. Tenant-aware routes keep public documentation separate from management and authentication surfaces.
- Customer journeys: a multi-level organization and customer model for implementation playbooks, ownership, invitations, and tailored onboarding work.
- Controlled authoring and publishing: rich-text editing, Markdown import, draft recovery, history, and an explicit published boundary.
- Grounded discovery: AI-assisted writing and hybrid search with confidence gating, source-citation checks, refusal behavior, and isolated diagnostic traces.
- Interactive API reference: OpenAPI 3.0 and 3.1 import, immutable revisions, controlled publication, searchable reference pages, and a guarded request playground.
- AuthorTipTap editor
- Save draftPrivate editable state
- PublishExplicit permission check
- ReadPublic documentation
Editing a published article must not change its public version until publication.
A problem I worked through
The editor and navigation tree can both change an article’s metadata. A publishing regression showed why those surfaces need a shared contract: stale editor state could overwrite a more recent rename, move, or ordering change.
The project now shares page-persistence logic and has a browser regression that exercises those changes before publishing. Related checks cover draft isolation and restricted authors. This turns a specific failure into repeatable evidence for future changes.
How I plan and verify changes
I start with the user-visible outcome, acceptance criteria, and a reproduction path for bugs. I map affected areas, security constraints, dependencies, and agent ownership before implementation, then define the checks that will demonstrate completion.
Complex changes get a written model of states, initiating events, protected behavior, failure paths, and recovery. I use that model to constrain implementation and to make sure tests exercise the real boundary where a failure could occur.
Verification combines TypeScript and unit tests, a disposable Supabase harness for real database policies, and Playwright browser flows. CI runs the full suite. Scoped checks support iteration; deployment is followed by checking the actual affected route.
For grounded discovery, I maintain a 50-case evaluation set covering direct, paraphrased, multi-source, and unanswerable questions. The suite checks retrieval, grounded answers, refusals, citations, and tenant boundaries. For the API playground, verification also covers private-network blocking, redirect validation, credential isolation, rate limits, and draft-versus-published behavior.
Skills used
Agentic development: task design, specialized agent roles, an automated context feedback loop, model and reasoning choices, and independent review.
Engineering: React and TypeScript, editor state, API contracts, Postgres permissions, and debugging across frontend and backend boundaries.
Delivery: Git branches and worktrees, scoped changes, regression tests, migrations, and Vercel releases.
ChartaFlow remains in development. The project gives me practical experience connecting customer needs to implementation and testing across a full application.
See how I direct AI development ↗