DxC: Natural-Language Content Workbench with 8-Step Pipeline & Local Memory

Business Panorama: 14 Skills Orchestrating an 8-Stage Pipeline

DxC (Document x Content) is a personal content workbench that runs inside Agent hosts such as WorkBuddy and Codex. It exposes 14 official Skills — interaction contracts that tell the Agent what to do, what to show, and when to pause for user confirmation. A single Master Skill starts or resumes an article; eight Process Skills handle Research, Brief, Outline, Body, Title, Visuals, Quality Review, and WeChat Delivery; five Foundation Skills manage Projects, Author Profile, Long-term Memory, Historical Articles, and Quotations.

From the user's perspective, the main flow is simple: bring a topic, a set of materials, or an existing article; converse in natural language to advance through the eight stages; preview the final result; confirm; the finished draft lands in the WeChat Official Account draft box. Long-term assets (profile, memory, historical articles, quotations) sit beneath this main line, feeding each new project with author identity, constraints, past work, and expression candidates. A Project Overview stores each article's current stage, enabling single-cursor resume — the user picks a project and DxC restores the exact working context without the Agent guessing progress.

Natural-Language Interaction Loop

DxC requires no web-based workflow configuration. The conversation carries goals, materials, content judgments, and user choices; the browser handles only QR-code authorization, template selection, and final preview. A typical operation spans five steps:

User states the goal (e.g., "continue last article" or "create WeChat draft").

The relevant Skill displays the current work context.

For example, "continue last article" first opens project selection; once the user picks the target article, DxC restores the current stage — the Agent never reads the project directory, guesses the last completed step, or assembles CLI parameters. "Create WeChat draft" sequences account selection, authoritative rendering, template preview, explicit confirmation, draft creation, and platform read-back. An opaque work item serves as a context handle passed unchanged between stages; the CLI parses stage, inputs, outputs, confirmation requirements, and the next action. Responsibilities are cleanly split: the Agent decides angle, structure, titles, and visual intent; the CLI governs progress, material validation, confirmed versions, and external writes.

Eight Stages, Each Producing Inspectable Artifacts

Research — verify facts and sources, compare viewpoints, retain evidence that supports article judgments.

Content Brief — define audience, problem, angle, and reader takeaway.

Outline — assign section tasks, argument order, and questions each part must answer.

Body — write the full article from research, brief, and outline; simultaneously apply publishing format and run an independent content check.

Title — generate candidates, lock the final title, bind it to the current body version.

Visuals — determine cover and in-article image purposes, generate or adopt real images, validate format, size, placement, and file safety.

Quality Review — check facts, structure, expression, reader value, and publishing boundaries; on rework, return to a specific content stage.

WeChat Delivery — complete account selection, authoritative rendering, template preview, final confirmation, draft creation, and platform read-back.

Users with existing materials may enter at any stage: a finished body can jump straight to Title or Visuals; a completed article can loop back to an earlier stage. After an upstream change, downstream content regenerates from the new version, and prior previews/confirmations become invalid. On next resume, DxC returns the single current work item — no parallel stage table needed. Each stage owns its completion criteria: body checks format, title checks selection and length, visuals check real images, delivery audits the final snapshot.

Creative Memory: Four State Types Feeding Future Articles

Continuous writing accumulates author identity, target audience, long-held views, business context, historical cases, and phrasing habits. DxC unifies these as Creative Memory managed in four categories:

Profile — a small, stable author portrait: identity, domain, audience, value promise, red lines, and baseline style. Loaded in full at project creation; changes only on explicit user setup, edit, or confirmed upgrade.

Memory — user-confirmed long-term preferences, principles, judgments, business context, and expressions. Mandatory memories (scoped with TTL) inject directly into the project; guidance and candidate memories are retrieved via local hybrid search.

Knowledge — quality-reviewed DxC final drafts plus user-imported historical articles. Each entry retains article, segments, and provenance; serves only as traceable reference.

Author Signals — pending signals from real creative acts (edits, selections, rejections, explicit feedback) after the user enables long-term learning. Agent-generated content never becomes author evidence.

Signals stay in a staging area: a single edit may apply only to the current article; promoting it to a long-term rule would affect every future project. At project creation, DxC assembles a fixed context snapshot: full profile, all applicable mandatory memories, topic-recalled guidance/candidate memories, and relevant historical article segments. The eight stages read this snapshot; mid-project global changes do not silently enter the current project — only an explicit refresh triggers reassembly and re-validation from the earliest affected stage.

Author Signals require cross-project accumulation: a candidate pattern must appear in at least two independent projects, include at least one direct user input/edit/selection/rejection/feedback, show consistent direction, and have no clear counter-examples. DxC proposes at most one upgrade candidate at a time. On user confirmation, the candidate graduates to Profile or Memory; on rejection, it is deleted; on deferral, it remains pending. Candidates never influence any article before confirmation. When a draft passes review and the body version remains unchanged, the final version is idempotently written to Knowledge keyed by project and version; re-review of the same version updates the existing record only.

Local Hybrid Retrieval: SQLite FTS5 + BGE Embeddings via ONNX Runtime

Memory and Knowledge reside locally, sharing retrieval infrastructure while keeping tables, state, and deletion rules independent. SQLite stores Memory records, article metadata, content segments, provenance, hashes, and vectors; indexes are rebuildable. Author Signals stay unindexed.

Literal recall uses SQLite FTS5 with trigram tokenization on titles, sections, and raw sentences — ideal for exact term, name, or sentence lookup.

Semantic recall handles paraphrased queries. DxC tokenizes locally with Tokenizers.js, runs the fixed Xenova/bge-small-zh-v1.5 q8 Chinese embedding model (512-dim) via ONNX Runtime Web single-threaded WASM executor.

At current historical-article scale, DxC computes normalized dot products directly for semantic similarity ranking — no external vector database, no SQLite vector extension. Query-time: FTS5 and vector search each produce ranked candidates; RRF (Reciprocal Rank Fusion) merges the two lists, then deduplicates by limiting segments per article. Only a few sourced results enter the project context. Model version, revision, quantization, vector dimension, and chunking rules form an index contract — any change demands explicit rebuild. If vector capability is unavailable, structured ground truth and mandatory memories remain functional; semantic search explicitly reports degraded mode. The local chain never scans the user's home directory, Obsidian vault, or cloud drives; external historical articles import only on explicit user file/directory selection, and full text never leaves the local machine.

Five-Layer Technical Architecture

Agent Host — WorkBuddy, Codex, etc.; provides conversation, file picking, content creation, result display, user confirmation. Research and writing use the host's built-in models and tools.

14 Official Skills — the natural-language product surface; define usage, visible results, choices, and stop points. Master Skill routes intent to the current stage; stage Skills hold no workflow state.

dxc CLI, Unified Business Contract, Local SQLite — owns workflow state, I/O, dynamic constraints, permissions, confirmations, idempotency, resume, and the unique next action; also manages local profile, memory, historical articles, projects, and material validation.

DxC Cloud — Fastify server handles identity, WeChat authorization, article upload, authoritative rendering, pre-flight checks, short-lived previews; MongoDB stores authoritative state; S3-compatible object storage holds immutable HTML and assets; Workers pull tasks and call WeChat APIs.

WeChat Open Platform — official interfaces for account authorization, material upload, and draft operations. Platform tokens and third-party platform secrets stay only in the cloud.

The Worker is the sole component that can create, overwrite, or delete WeChat drafts. After create/overwrite, it calls the WeChat draft-readback API to verify title, author, digest, body, cover, and in-article images. "External write result unknown" is a stop condition: the task retains its intent and idempotency key until the result is confirmed, preventing duplicate draft entries. The codebase uses pnpm workspace monorepo; CLI, Server, Worker, and shared contracts are TypeScript strict. Cloud runs Node.js 24; CLI uses Commander; tests use Vitest; structured logging uses Pino. The first preview page is minimal server-rendered HTML — no frontend framework introduced. Current product delivers local deterministic capabilities via CLI; user historical article full text stays local.

Profile, Projects, and Long-Term Content Assets

Author Profile built via guided Q&A users can complete the full profile once or update single fields (audience, tone, red lines). DxC saves merged versions — no manual config file editing.

Project Overview lists registered articles with name, current stage, and status. Re-linking a project requires explicit directory selection.

Historical Article Knowledge Base supports explicit import, status view, search, adoption, and deletion. Adopted content retains provenance and verbatim-use boundaries.

Long-term Memory supports save, view, correct, and archive.

Quotation Library has a dedicated entry; original expressions, third-party citations, attributions, and verbatim permissions are preserved. Backed by unified Memory; search returns candidates only — adoption remains a user decision.

At new project creation, applicable long-term assets enter the fixed context snapshot. They do not auto-advance the eight-stage flow nor rewrite already-confirmed articles.

Current Target Scenarios

DxC serves creators who continuously produce long-form content, need to preserve personal context and stylistic choices, and deliver finished drafts to WeChat Official Accounts. Users can start from a topic, research materials, an existing outline, or a partial body. Delivery stops at the WeChat draft box; formal publishing and mass sending remain manual in the WeChat backend. DxC does not auto-scan historical directories, does not inject candidate memories into bodies, and does not offer multi-platform publishing or a traditional web CMS.