Back to buildsBUILD RECORD

Working Memory Content Operations / Content handoff tooling / 2026

Checking a draft before it reaches the publishing system.

A local Node CLI checks draft content and links with the portfolio's own validator, then records exactly which files and content were checked.

THE WORK

The project.

Working Memory Content Operations prepares project stories and notes for the portfolio without needing a running content service. The Node CLI imports the website's own validator, checks the draft bundle and returns a compact report. Duplicate identities, missing project links and text changed during normalization stop the handoff.

The report keeps file bytes, canonical content and validator identity separate. That makes it possible to tell a formatting change from a changed draft or a different validation module. The tool stops at the report; the portfolio's content service still owns saving revisions and publishing.

IMPLEMENTATION

Design choices.

  1. Reusing the website's validator keeps the handoff rules aligned with the receiving system. The selected checkout still has to be trusted, because importing its validator executes local code.
  2. Comparing content hashes before and after validation catches changed text while allowing differences in JSON indentation and key order.
  3. Requiring linked projects in the same bundle makes the check independent of a running service. The cost is an extra project file even when a note refers to a project already on the website.

HOW IT FITS TOGETHER

Architecture.

  • The CLI resolves the selected website and draft directories, filters the recognised JSON filenames and imports validatePayload and contentHash from that website checkout.
  • Each record must validate, remain Draft and retain the same canonical content. Bundle checks then reject duplicate identities and article links without a matching project file.
  • The output reports hashes for file bytes, canonical content and the validator file. It omits full payloads and never imports the content store, so producing a report cannot save or publish a revision.
Explore the architecture map9 components · 10 connections

A draft-only companion to the website validator

Per-record and bundle checks produce a local handoff report. Saving and publishing remain with the website's content service.

Direct callResponse / returnBlocked / denied
Operator and files
Content Operations CLI
Handoff result

Scroll or drag the background to move. Use the zoom buttons to resize.Arrow keys move between components. Enter selects.

Choose a component to explore

Select a numbered component on the map or use the component menu. Its details and connections will appear here.

No component selected.

All connections (10)
  1. 01 · Explicit local invocation04 · Arguments and discoveryexplicit options · Direct call
  2. 04 · Arguments and discovery03 · Project and article filesdiscover payload files · Direct call
  3. 03 · Project and article files05 · Per-record checksparsed records · Response / return
  4. 02 · Website validation module05 · Per-record checksshared validation functions · Direct call
  5. 04 · Arguments and discovery08 · Local failureinvalid invocation · Blocked / denied
  6. 05 · Per-record checks08 · Local failureinvalid or changed payload · Blocked / denied
  7. 05 · Per-record checks06 · Identity and link checksaccepted local drafts · Direct call
  8. 06 · Identity and link checks08 · Local failureduplicate or missing project · Blocked / denied
  9. 06 · Identity and link checks07 · Build validation reportconsistent batch · Direct call
  10. 07 · Build validation report09 · Draft handoff reportJSON report only · Response / return

MADE WITH

Node.js · JavaScript ESM · JSON · SHA-256 · Shared content validator · CLI

ACCESS & INPUT

Security controls.

  • Drafts with publication dates are rejected. A schema-valid payload is also rejected if normalization changes its canonical content.
  • The script imports the validator rather than the content store. There is no service-write or publication operation in its workflow.

CHECKS & RESULTS

What was checked.

A source review shows what the code does. It is not a fresh test of the running app.

  1. Code and development records reviewedReviewed

    The code, tests and available development records were checked. Reported test results keep their original scope. No fresh app or live deployment check was run for this write-up.

    Scope of this check
    Code review, not a fresh run of the app

NEXT

Still to work through.

The validator hash identifies one file, not its imported dependencies. The runner also retains an LMS ranking rule and requires the project record for article-only updates. Those are visible limits of this local handoff tool, not publication guarantees.