Why
Before this, publishing Build content relied on manual judgment: whether content was compliant, whether its structure was complete, and whether the runtime could read it correctly after publishing all lacked a unified checkpoint. Once the content format diverged from runtime expectations, problems often only surfaced after publishing.
The goal of this change was not to add features, but to turn "can this content be published" into a question that can be answered before publishing: content first passes contract validation, then CI gates, and only then enters the publishing flow.
What changed
The changes centered on several interlocking parts: workflows, the content directory, documentation, the runtime content module, scripts, and tests.
On the content side, schema and topics definitions were introduced, making the relationship between notes, variants, and topics explicit; the script side validates content against the contract; the test side covers both the PHP and Node check paths; the workflow side strings preview and gates together so that checks must pass before publishing.
The release itself concluded with a production deployment; the deployment record was written into the repository documentation and tagged with the corresponding validation tag. For the specific version, commit, artifact digest, test counts, and corpus counts, see the facts above.
How we verified it
Verification had two layers. The first layer is automated checks: the PHP and Node check suites run in CI, with several gates, and only when all pass is it allowed to continue. The second layer is production verification: after the artifact was deployed to production, the runtime reported its own state and the scale of content it loaded.
Two corpus figures from different points in time need to be distinguished:
- Production corpus at the time of the 1.3.5 deployment | 5 notes / 15 variants / 13 topics
- Current authoring corpus as of the current repository state | 6 notes / 18 variants (1 of which is still unpublished)
The former is the runtime snapshot at deployment time; the latter is the repository's current content state. It is normal for the two to differ: the repository can contain drafts that have not yet been published.
- Version
- 1.3.5
- Main release commit
- 57bf785a0bcd6e886397de776cbe7bd7156fd64c
- Production provenance
- 4b4ec32a3aac70a8222ca7255f0db38fb6683200
- Deployed artifact
- weour-core-1.3.5.zip
- Artifact SHA-256
- f660c0d9b48cbe774a3ba10d380eedfbf9a4fee5cf1a49c97c024ee7c1ee28ab
- Plugin manifest SHA-256
- 952f570124787702fc8c71ce6ebd5410dca3099730b212d805189f3764d2a703
- Deployment environment
- production
- Deployment state
- deployed
- Runtime state
- ready
- Runtime version
- 1.3.5
- Runtime module count
- 12
- Test counts
- PHP 1100 checks / Node 97 checks
- Gate count
- 5
- Production corpus at deploy time
- 5 notes / 15 variants / 13 topics
- Current authoring corpus
- 6 notes / 18 variants (1 of which is still unpublished)
What it does not mean
It does not mean content publishing no longer needs manual judgment. The pipeline checks the contract and structure; it does not check whether the content itself is appropriate or worth publishing.
It does not mean everything in the repository is live. The repository's current content count is greater than the runtime count at deployment time; the difference comes from drafts that have not yet been published.
It also does not mean this flow already covers all future content forms. This validation targeted the current content contract and runtime read path; forms outside the contract are not within the scope of this validation.
Finally, it is not a commitment to future versions, timelines, or capabilities. What is recorded here is a release and validation that already happened, and the evidence supporting it.