Rebrand direction · interactive preview
ConceptNot production
The decision layer for agent work

Turn agent output into a decision.

Publish rich work from any agent. Let people verify sources, request changes, approve outcomes, and send decisions back—without flattening the work into a PDF.

Any agentCodex · Claude · Cursor · API
Live HTMLResponsive · interactive · editable
Human controlDiffs · approvals · audit trail
>_Codex published from html-docs
In review
Decision brief · 26 July 2026

API authorization redesign

A capability-based model that makes agent access explicit, reviewable, and safe by default.

42%less policy code
6named scopes
0silent fallbacks
Recommendation Ship capability checks behind a compatibility layer, then migrate one write path at a time.
One coherent loop

The artifact stays live from creation through approval.

01Publish

An agent, import, or person creates the same first-class artifact.

02Review

People verify evidence and request typed, owned changes in context.

03Decide

The rationale, final version, and accepted patch become a durable record.

Inbox

Assigned to you

Work waiting for judgment

Reviews, approvals, mentions, and agent revisions in one queue.

ArtifactNeedsStateUpdated
API authorization redesign>_Codex · html-docs · e5b39f9
Your approval2 changes resolved
In review
12 minby Maya
Q3 launch narrativeCClaude · launch workspace
Review3 new sections
Ready
47 minby Agent
Enterprise packaging proposalRRaunaq · Product
DecisionRationale required
Blocked
2 hrby Finance
Region sync incident reviewCIGitHub Action · incident-142
Source alertCommit changed
Stale
Yesterdayby CI
New onboarding journeyFFigma import · Growth
Question@mentioned
Approved
Yesterdayby Ana

New artifact

One object, three entry points

Start with the work you already have

Agent, import, and blank creation all become the same reviewable artifact.

Agent-first creation

Give an agent a decision to prepare

The agent gets a live artifact URL, scoped workspace context, and a structured contract. You remain the owner of review and publication.

/
API authorization redesignSaved
In review
>_Codex · task 8c1d · repo html-docs Source e5b39f9 · checked 3 min ago
Decision brief · security architecture

API authorization redesign

Move from route-specific ownership checks to explicit capabilities shared by humans, API keys, and agents.

42%less policy code
6named capabilities
3migration phases

Context

HTML Docs now has multiple creation and mutation paths: the web editor, CLI, public API, Docsmith, and connected agents. Each path currently reconstructs authorization from route context.

Recommendation

Adopt a capability-based access policy that evaluates the actor, artifact, requested operation, and provenance in one transaction boundary. Begin with write operations and keep read compatibility during migration.

Why now

The structured editor gives human and agent actions a common command model. Authorization should attach to those commands—not to the UI surface that happened to issue them.

  • Every mutation has a named scope and attributable actor.
  • Agents can request access without inheriting a user’s full authority.
  • Reviewers can see what an integration is allowed to change.
2?
/
API authorization redesign
Review requested by Codex · 16 min ago
Publish
Understand
Review
Decide
Return
Decision requestedApprove capability model and phase-one instrumentation
Accountable ownerMaya ChenSecurity lead
Required reviewers2 of 2 completeProduct · Platform
DueToday · 5:00 PM3h 18m remaining
Decision brief · 4 minute read

API authorization redesign

Move from route-specific ownership checks to explicit capabilities shared by humans, API keys, and agents.

What changed since your review

Codex addressed both requested changes: the recommendation now names six capabilities, and the migration section separates enforcement from observability. No evidence sources changed.

Recommendation

Migration sequence

  • Instrument existing routes and compare shadow capability decisions.
  • Remove route-local ownership checks after thirty days without divergence.

Decision requested

Approve the capability model and phase-one instrumentation. This decision does not authorize removal of existing ownership checks.

Evidence state
Repository revisione5b39f9
Sources verified8 of 8
Changed since generationNone
How review actually works

Review is a controlled state machine—not a comment sidebar.

A review begins with a named decision, named accountable people, and a frozen comparison point. Conversation can be messy; the product state cannot. Every request is typed, every revision is previewed, and completion has explicit gates.

01 / INTAKEDefine the ask

Owner, approvers, due date, decision statement, and review criteria are required before notifications go out.

02 / ORIENTUnderstand the delta

Reviewers see a summary, provenance, source freshness, and exactly what changed since their last visit.

03 / RESPONDGive typed feedback

Question, change request, note, and decision are distinct objects with scope, owner, and resolution state.

04 / REVISEPreview proposals

A person or connected agent proposes small semantic patches. Reviewers accept, reject, or request another revision.

05 / CLOSERecord the outcome

Required approvals, unresolved blockers, rationale, final version, and return-to-agent receipt form the decision record.

Who does what

Roles replace ambiguous “shared with.”

A reviewer can participate without being an approver. One accountable owner is responsible for getting the work to a decision.

OwnerDefines the decision, chooses required reviewers, resolves scope, and closes the review.
ApproverMust explicitly approve or request changes before the artifact can reach the decided state.
ReviewerCan ask questions, leave notes, and create change requests; approval is optional.
AgentCan read assigned feedback and submit proposals, but cannot resolve its own request or approve.
Feedback anatomy

Comments gain workflow meaning.

Version rules

No moving target.

1
Review baseline is frozenEach reviewer compares against the version they were asked to review.
2
Material changes reopen gatesAccepted revisions notify affected approvers and mark their approval stale.
3
Evidence has freshness stateRepository or source changes show as alerts rather than silently changing claims.
4
Closure is immutableThe decided version and rationale remain addressable even when a new review begins.

Agents & API

Bidirectional by design

Agents participate in the review loop

Create artifacts, read feedback, propose scoped revisions, and receive decisions through one contract.

Definition

A connected agent is a participant with identity and a return address.

It is not an embedded chatbot. It is Codex, Claude, Cursor, or a custom workflow authenticated as a named integration, linked to the task that produced an artifact, and allowed to perform a small set of review-aware operations.

CONNECTED AGENT = identity + scoped tools + task link + event return path
01Create

Publishes an artifact with source and task provenance.

02Listen

Receives assigned questions and change requests.

03Propose

Returns scoped, inspectable document operations.

04Wait

A human accepts, rejects, or asks for revision.

05Resume

The outcome and accepted patch return to the original task.

IdentityWho acted?

Integration name, provider, workspace, installation owner, and agent task are recorded on every mutation.

CapabilitiesWhat can it do?

Explicit scopes such as create artifacts, read assigned feedback, or submit proposals—never a shared human session.

Context linkWhat work is this?

Artifact regions link back to repository files, source revisions, prompts, recipes, and the originating agent run.

Return channelHow does it continue?

MCP polling, webhooks, CLI watch, or task callbacks deliver feedback and the final decision upstream.

Connected agents3 integrations
CodexConnected to 4 repositories
read:artifacts
write:proposals
read:feedback
Active
Claude CodeMCP · personal connection
read:artifacts
write:artifacts
Active
Launch workflowCustom API · workspace owned
write:artifacts
read:decisions
Review
Return pathWhat closes the loop
01
Typed feedback is machine-readableQuestion, change request, note, and decision each have status, owner, scope, and thread.
02
Revisions are proposalsAgents submit semantic operations with before/after preview and inverse actions.
03
Decisions return upstreamThe originating task receives the outcome, rationale, version, and accepted patch set.
Agent quickstart

Install the review surface in one command.

The same contract powers Codex, Claude, the CLI, and custom agents. Scopes remain explicit and revocable.

$ npx html-docs connect --mcp

workspace  acme-product
scopes     read:artifacts, write:proposals,
           read:feedback, read:decisions
connected  ✓ codex

$ html-docs publish ./decision-brief.html
created    artifact hdoc_8c1d
review     https://html-docs.com/a/hdoc_8c1d

Contract capabilities

Create a live artifactartifacts.create
Read unresolved change requestsfeedback.list
Propose a semantic patchproposals.create
Receive final outcome and rationaledecisions.watch
01 / NEUTRALAny agent in.

No model lock-in. HTML and a documented contract are the shared surface.

02 / SCOPEDProposals, not silent rewrites.

Every mutation names its target, actor, diff, and inverse action.

03 / HUMANJudgment stays visible.

Approval and publication are deliberate product states, not generic comments.

04 / DURABLEThe decision is the record.

Artifact, evidence, review history, and rationale remain one addressable object.

What a connected agent can do

Create or update artifacts within granted workspace and artifact scopes.
Read feedback explicitly assigned to the integration or originating task.
Submit revisions as semantic proposals with a preview and inverse operation.
Receive accepted changes, decisions, and rationale through its configured return channel.

What it cannot do by default

×Impersonate a reviewer, inherit a human’s broad session, or read an entire workspace.
×Silently rewrite a version currently under review or resolve its own change request.
×Approve, publish externally, change access, or widen its own capabilities.
×Continue after revocation; tokens and event delivery stop immediately.
One review loop, as an event traceartifact hdoc_8c1d · task codex_7fd2
artifact.createdCodex publishes version 1 from repository revision e5b39f9.
feedback.assignedMaya creates a blocking change request on region “Recommendation.”
task.resumedHTML Docs returns the typed request and scoped region context to task codex_7fd2.
proposal.createdCodex submits two document operations; neither changes live content yet.
proposal.acceptedRaunaq accepts both operations. Version 2 becomes the new review candidate.
decision.completedMaya approves with rationale; outcome and accepted operations return to Codex.
Updated