Skip to navigation
ReferenceStatus and Configuration

DocsFab Implementation Status

Dev
View as Markdown

DocsFab is in project stage alpha: named internal users run the local CLI and live-agent as the current product. Public release remains blocked. Use this page to avoid interpreting a target-product concept as released behavior. The current candidate product reference model is DOCSFAB-PRODUCT/v0.29. It registers the current repository evidence boundary. Later tracker, implementation, and runtime changes remain development evidence until a new source item and immutable model version reconcile them. For more information, refer to DocsFab Status and Configuration Reference.

Snapshot

The following table summarizes the current interpretation of each boundary.

BoundaryCurrent interpretation
Public releaseRelease blocked. No canonical DocsFab release record exists.
Complete first-run experiencePlanned. Local CLI and live-agent are the current product; the complete Blueprint first-run is not.
Local runtime and quality workflowsRepository-tested or implemented with integration pending, as identified in the inventory.
GitLab and Fern deliveryIndividual paths have repository tests or CI evidence; no row establishes end-to-end release authority.

Treat every state as scoped to its evidence cell. A passing test, source build, preview, or retained composition-execution run does not promote a capability to a released product.

Status Definitions

The following table defines each state.

StateMeaning
Repository-testedThe repository contains implementation and focused tests that pass in a local checkout. This is current-product evidence for that capability, not a public-release claim.
Implemented, integration pendingCode or documentation exists, but the complete DocsFab composition or delivery path has not been verified.
Pilot-verifiedThe evidence cell records a successful live pilot journey. This does not establish other deployment modes, broader qualification, or public release.
PlannedThe canonical product reference model describes the capability, but the repository does not establish working behavior.
Release blockedA release record or required deployment, security, legal, support, or verification evidence is absent.

Capability Inventory

Knowledge and Convergence

The following table lists the state and evidence boundary of each knowledge and convergence capability.

CapabilityStateEvidence boundary
Source-thread JSON schemas, validation, and rendered viewsRepository-testedSchemas, validator, and source-thread records exist under packages/knowledge; package tests pass.
Session-transcript evidence miningRepository-testedSkill, secret-safe miner, and five Python tests exist.
Knowledge event store and local control-plane APIRepository-testedLocal tests cover replay, concurrency, stale writes, authority, artifacts, workflows, adapter boundaries, and a sealed knowledge-snapshot export.
Product-model interview procedureImplemented, integration pendingConsent-aware skill and artifact contract exist. No production interview UI is established.
Source-thread synthesis and model packageImplemented, integration pendingSkill, synthesis contract, and DocsFab candidate model versions exist. A persistent autonomous reconciler is not established.
Bounded context compilation for one hosted jobRepository-testedLocal tests pass. Live hosted compilation remains integration pending.
Merge-triggered report-only reconciliationRepository-testedLocal tests pass. On the two-project pilot from September 10 to October 19, 2026, each of the 1,719 and 8 merges admitted from poll mode received exactly one poll-driven reconciliation request, and 8 of the docsfab-pilot merges later received one operator-approved re-drive after quarantine. The poller skipped 140 earlier merges at admission because their actor was unmapped, and one later merge was never observed (issue 2610), so live merge reporting is not yet verified.
Owner-controlled Slack advisory summariesImplemented, integration pendingQuestions-only is the default. Protected initial configuration and owner-only Slack status/mode commands control summaries for new advisory results. Real Slack command, delivery, and quiet clean-merge evidence remain separate deployment acceptance.
Structured accountable-owner adjudicationRepository-testedLocal tests pass. From September 30 to October 18, 2026, the pilot sent 29 structured questions in a Slack thread to its one self-designated product-decision owner. The owner answered 16, and 13 answers resumed their stopped reconciliation to a final result; 11 questions expired unanswered. Routing through a confirmed ownership map is not yet evidenced.
Governed post-adjudication model and projection convergenceRepository-testedLocal tests pass. On the pilot, accepted owner decisions published and merged new model versions, and the approved model reached generation 5 on October 16, 2026. Regenerating PRD, SRD, and POR projections from those decisions is not yet live.
Bounded adjudication and post-reconciliation documentation convergenceRepository-testedThe synthesis skill prompts for one-at-a-time adjudication and defines regeneration plus an all-family readiness rescan. Autonomous semantic reconciliation remains incomplete.

The default merge-reconciliation interaction posts governed questions only. The mapped product-decision owner can use /docsfab reconciliation status and /docsfab reconciliation mode questions|advisories in the approved project conversation. Advisories mode adds summaries for newly completed eligible advisory analyses, without owner mentions or historical backfill. Clean and informational-only results remain silent in both modes. Failed, missing, corrupt, quarantined, retried, and superseded results do not become Product Reference Model conflicts. An eligible conflict produces one request that mentions the uniquely mapped accountable owner. An attributable reply can resume the existing candidate lineage, but it cannot approve, publish, merge, or deploy.

The current worker classifies changed paths; it does not semantically compare source changes against the Product Reference Model. Advisory summaries expose that screening result without changing finding severity or owner authority. Visibility settings persist across restart, and disabling advisories suppresses pending unattempted deliveries. Uncertain Slack posts remain inspectable rather than being automatically reposted. General debug levels and raw log streaming remain outside this slice.

Quality and Documentation Behavior

The following table lists the state and evidence boundary of each quality and documentation behavior capability.

CapabilityStateEvidence boundary
NVIDIA-derived writing profileImplemented, integration pendingA lineage-bearing compact profile is packaged under packages/quality; broader quality-pack integration remains incomplete.
Central skill catalog and runtime-bound quality workflowsRepository-testedEight canonical skill sources exist under one inventory. Source-fact inventory is a Pin A step of verify-technical-accuracy, not a ninth catalog identity. Focused polish is part of write-documentation; the standalone polish-documentation skill is retired. Exact staged copies are hash-locked in the runtime crate. Four validated manifests under packages/runtime/workflows/ define the operator-runnable jobs. Representative-audience and broader comparative live-model evidence remain pending.
Five-function quality model and many-to-many capability coveragePlannedProduct models v0.4 and v0.10 define the provider-neutral functions. Runtime bindings and complete evidence are not implemented.
Clean non-author adversarial reviewImplemented, integration pendingProduct model v0.4 requires a clean subagent for agent-authored content and a different human or clean agent for human-authored content. Explicit reviewer-independence attestation remains incomplete.
Conditional, bidirectional SRD lifecyclePlannedProduct model v0.4 makes the reference model canonical and SRDs optional inputs or outputs. Current shared skills still implement the narrower SRD-first preview.

Runtime and Execution

The following table lists the state and evidence boundary of each runtime and execution capability.

CapabilityStateEvidence boundary
Governed documentation runtime and docsfab CLIRepository-testedThe runtime exposes four catalog workflows, including composed creation, update, and restructuring jobs. docsfab --version reports the packages/runtime/package.json version, and docsfab help exposes the current command catalog. The package is not established here as an approved product release.
Derived runtime state preparationRepository-testedruntime:prepare generates and verifies the derived graph once in dependency order. This is a local CI path; exact-merge integration remains subject to CI evidence.
Provider-neutral Pi executable compositionsRepository-testedExplicit --composition <id> routing supports NVIDIA, direct OpenAI, and direct Anthropic connections. Provider-offline contract tests cover all three transport families. Every composition-execution result remains technically unapproved and not release eligible.
Codex and Claude Code native composition preflightImplemented, integration pendingdocsfab composition list exposes two preflight-only compositions. Contained native execution and role qualification remain unimplemented.
Cross-harness development pilotImplemented, integration pendingdocsfab composition pilot-campaign can collect live development evidence only with explicit acknowledgment of the uncontained boundary. It provides no ranking, technical approval, or merge authority.
Bounded local Docker and Brev runtime previewsRepository-testeddeploy/compose/ and deploy/brev/ package and smoke the current CLI. These paths do not provision a complete Blueprint environment or establish release readiness.
Complete NVIDIA Blueprint first-runPlannedEpic #96. The complete one-command journey, managed Brev provisioning, approved model and serving profile, live watch, and release evidence are not established.
.docsfab.json project configurationRepository-testeddocsfab init previews and applies a digest-bound configuration containing the GitLab remote and default branch. Private state stays under .docsfab/ or DOCSFAB_CONFIG_ROOT.

GitLab and Documentation Delivery

The following table lists the state and evidence boundary of each GitLab and documentation delivery capability.

CapabilityStateEvidence boundary
Phase A GitLab merge-request notificationRepository-testedThe host package can emit one terminal or needs-decision note through a fake-testable transport. It does not provide a live GitLab HTTP client.
Existing-MR review summary notePilot-verifiedOn October 09, 2026, the hosted review pilot delivered one bot note for a frozen merge-request head. This proves one live review-to-note journey. This evidence does not qualify webhook intake. Hosted quality validation remains an open follow-up.
Phase B GitLab mention-submitRepository-testedA signed Note Hook can parse @docsfab run <workflow> and call the host submit/observe spine. Mentions cannot mint --allow-write.
Provider-neutral merge-request change-event intakeRepository-testedLocal tests cover GitLab open, update, merge, and close normalization. Live receiver testing remains integration pending.
PostgreSQL host-service persistenceRepository-testedLocal tests cover project-bound PostgreSQL persistence. This is local harness evidence, not a live deployment.
Guarded PostgreSQL 16 bootstrapLive infrastructure, application pendingLocal tests pass. DocsFab schemas and project bindings remain integration pending.
Project activation package preparationRepository-testedLocal tests cover closed activation inputs. Live activation remains integration pending.
Provider-neutral polling service integrationImplemented, integration pendingEach project requires one sealed poll or webhook policy without fallback. Two pilot projects have polled since September 2026, and a sample on October 19, 2026, measured a completed poll every 30.9 to 32.6 seconds. One merge on October 16, 2026, was never observed (issue 2610), so live polling is not yet verified. Webhook mode has no live evidence.
Runnable multi-project host ingressImplemented, integration pendingLocal tests cover per-project PostgreSQL-bound runtime composition. One supervised pilot service runs two projects with separate PostgreSQL bindings, and 8 restarts from October 13 to 19, 2026, returned without a rollback. Cross-project worker isolation and a live epoch rollover are not yet evidenced.
Host submit/observe spineRepository-testedDurable submit, observe, cancel, pause, and resume exist for one catalogued work packet under packages/host/src/jobs/.
Bounded hosted dispatcherRepository-testedLocal tests cover digest-bound hosted dispatch. This evidence is not a live provider or service deployment.
Activated repository grantsRepository-testedHost persists a versioned grant for one GitLab host and numeric project and evaluates named operations. Workers receive a decision, not a token.
GitLab publisher credential brokerRepository-testedHost issues opaque task-scoped leases to a fixed-purpose publisher. A lease is not repository authority.
Host-owned create-or-reuse draft MRRepository-testedTyped create-draft-mr apply exists under packages/host/src/gitlab-publisher/apply.ts. A live SCM call is not claimed here.
Local-user --draft-mr publishRepository-testedRuntime local-user delivery can open a draft MR through glab in focused tests. Live GitLab execution is separately authorized and not claimed here.
Fern site deliveryImplemented, integration pendingCI defines merge-request Review Apps, a default-branch build, and SemVer-tag publication using Fern components 0.24.0. Pipeline configuration does not prove that a release was approved or published successfully.
Repository-automation modeImplemented, integration pendingMailbox notify, mention-submit, thread-reply resume, merge-request change-event intake, merge-triggered report-only reconciliation, and the bounded host-job consumer exist as repository-tested paths. On the pilot, poll-mode change-event intake, merge-triggered reconciliation, and the host-job consumer run live; the rows above record what was measured and what is not yet verified. Approved live policies and end-to-end evidence for the other paths remain open.

Interaction, Deployment, and Release

The following table lists the state and evidence boundary of each interaction, deployment, and release capability.

CapabilityStateEvidence boundary
Hosted Slack-first core deploymentPilot-verifiedThe pilot core service and project were active for the October 09, 2026, review-note delivery recorded in issue 2197. This establishes one live hosted workflow, not full host qualification; webhook and review-quality follow-ups remain open.
Interactive MCP, Slack, or chat modeImplemented, integration pendingLocal tests cover one deployment-level Slack Socket Mode connection with project-bound ports. MCP and other chat adapters remain planned.
Local CLI interaction modeRepository-testeddocsfab live-agent provides one persistent, interactive Pi conversation for a local repository. Focused tests establish the entry point, capability loading, and resume behavior.
Fully hosted DaaS modePlannedProduct intent defines a hosted backend and purpose-built application experience; no released service or UI is established.
Target onboarding journeyPlannedThe authored design covers local Docker, Brev without nested sandboxing, immediate CLI onboarding, one governed job, and live watch. Operational instructions and the exact model profile remain open.
Authenticated multi-user servicePlannedIdentity, tenancy, broker, and service-operation contracts are not released.
Brev reference deployment and model guidanceRelease blockedDocsFab sends inference to the model endpoint that you configure with docsfab setup and does not depend on a NIM. Any demonstration model, guidance on region, data policy, quota, fallback, and cost owner for the endpoint you choose, the Brev Launchable, and deployment evidence remain open.
Public releaseRelease blockedNo canonical DocsFab release record exists.

One-Shot Slack Questions

The host implements the bounded Stage 1 Slack question path. A mapped user can run /docsfab ask <question> (free text, optional target=<repo-relative-path> as the first or last word; without one, DocsFab answers from the tracked documentation pages that best match the question and names them in the answer) when both the project dispatcher policy and that user route activate live-agent-turn. The host persists the opening thread and turn identity, submits one job through the normal spine, and runs the read-only hosted workflow. The run record keeps the frozen scope. With target=, the turn runs against that page. Without one, the frozen scope names the project’s landing page, and the runtime replaces it with the pages the documentation index approves before the model’s first step. The host then loads the terminal answer from project-bound content-addressed storage and delivers at most three ordered chunks to the same thread. A top-level @-mention of the DocsFab app asks the same way, with the words after the mention as the question, and its replies go in the mention’s own thread. In a direct message whose route lists live-agent-turn, a top-level message asks the same way. When one project’s registry entry sets slack.unboundAsks, that project answers questions in every Slack conversation no project is bound to (a direct message to DocsFab, or a channel DocsFab is in that has no route or command channel), from anyone in the workspace, with no channel membership check. There, a top-level @-mention, /docsfab ask, or a top-level message in a direct message opens a read-only session answered in its thread; an @-mention inside another thread gets usage guidance instead. /docsfab help there says how to ask, every other command is refused as before, and status and reconciliation reports stay in each project’s report channel. Without that setting, an @-mention in a channel that no project serves gets one reply that says so and names the channels where every member can use DocsFab.

Controlled component tests cover adapter-to-dispatcher-to-runtime-to-run-record flow, duplicate ingress, restart delivery, project routing, denied admission, failure notices, answer bounds, and the unchanged terminal-pointer guard. Conversation resume, progress and cancel controls, writes, MCP, deployment, and a real Slack/model exchange remain pending.

Evidence Sources

Use the following checked-in sources to verify the inventory:

The previously affected brace-expansion production path is resolved. DocsFab pins @earendil-works/pi-coding-agent@0.84.4, whose locked nested dependency is brace-expansion@5.0.9, past the 5.0.8 patch for GHSA-mh99-v99m-4gvg. The dependency check now runs without an active exception and fails if an affected version is reintroduced. This focused remediation is not a general production-security or release-readiness result.

Interpretation Rule

Conceptual pages can explain the target product when they label that boundary. Procedures and reference pages must use verified commands, schemas, and interfaces. Release notes require a canonical release record and cannot be generated from plans alone.

The following pages provide related information: