Happyin Knowledge Space¶

Project Identity¶

Happyin Knowledge Space is a public technical reference. Markdown in Git is the content source and historical record; the static site is its rendered delivery surface. The baseline revision cited above completed the Cloudflare deployment workflow successfully on 2026-06-19; the current release requires its own workflow and live-page checks.

Content and Navigation Model¶

The build-time registry in hooks/stats.py defines 26 accepted content domains. It recursively counts Markdown below those domain directories while excluding each index.md; tags remain free-form discovery metadata.

The repository has no explicit nav: mapping in mkdocs.yml. MkDocs therefore derives navigation from the docs/ tree, while Material's navigation.indexes, navigation.sections, navigation.expand, and related features control the rendered navigation behavior.

Relevant project concerns map to existing domains:

• architecture — content boundaries and system documentation
• llm-agents and llm-memory — agent-oriented retrieval and durable context
• data-engineering — generated metadata and validation patterns
• web-frontend — rendered site behavior
• devops — CI build and Cloudflare Pages delivery

Implemented Publication Path¶

docs/{domain}/{article}.md
          |
          v
MkDocs hooks (stats, validation, links, descriptions, wiki-links, public checks)
          |
          v
mkdocs build --strict
          |
          v
GitHub Actions on master -> Wrangler -> Cloudflare Pages -> happyin.space

.github/workflows/deploy-cloudflare.yml runs on qualifying pushes to master and performs mkdocs build --strict before pages deploy site --project-name=knowledge-space --branch=main. Separate GitHub Actions validate article format, freshness, and internal links; the deployment workflow does not declare those jobs as dependencies.

The Cloudflare configuration also defines a DB binding for the happyin-subscribers D1 database. That binding alone does not establish a news or project-history API.

Repository-Backed History¶

These are Git-backed milestones, not a reconstructed marketing timeline. A commit proves the repository state it contains; it does not by itself prove a later live-site state.

Separate News Data Repository: Boundary¶

AnastasiyaW/diffusion-love-news is a separate public repository. Its published main branch now contains a version 1.3 JSON feed with 329 canonical items and 264 derived project records. The release at 730f7cf adds evidence-bearing lifecycle events and claims, explicit domain references, deterministic project timelines, and schema/build checks.

AnastasiyaW/diffusion-love-web is the separate consumer. Release c4a2e55 validates feed versions 1.2 and 1.3 at the network boundary and renders project passports at /project/{family_slug}. Its GitHub CI and Cloudflare Workers build completed successfully; Workers version 369017c1-56e7-4730-a07b-9f6c8a37d037 received 100% of production traffic. Both the portal and the Happyin project route returned the expected Cloudflare Access login redirect on 2026-08-21. This proves the protected route and deployment, not an authenticated visual render.

No tracked file in knowledge-space consumes the JSON feed. The open data contract, Access-protected portal, and this public technical reference remain separate delivery surfaces joined by explicit repository and project IDs.

Evidence Rules¶

• A repository commit proves only the change visible in that commit.
• A live HTTP response proves availability at the observation time, not a past change date or cause.
• Claims imported from a separate repository require a versioned source and explicit integration evidence.
• Inferred relationships must be labelled inferred; they are not verified facts.
• Private source text and provider transcripts do not belong in public data.

Local Verification¶

Run the repository checks from its root:

python hooks/freshness_check.py --ci
python lint.link-check.py --strict
python lint.py
mkdocs build --strict

The deployment workflow is the authoritative automation for publishing. A locally added article is not a live page until a source revision containing it has completed that workflow.

Gotchas¶

• Assuming an explicit navigation file exists: there is no nav: list in mkdocs.yml. Fix: preserve the docs/ hierarchy and verify the rendered MkDocs navigation.
• Equating a successful content validation job with deployment: those are separate workflows. Fix: inspect the Cloudflare deployment run for the relevant commit.
• Treating the D1 binding as a project-history backend: it only declares a subscriber database binding. Fix: require implemented handlers and consumer tests before documenting an API.
• Assuming a branch-addressed CDN updates atomically: jsDelivr may continue serving the previous compatible feed after main changes. Fix: verify the commit-addressed GitHub Raw payload for release evidence and keep the consumer compatible with both supported schema versions during propagation.
• Calling the separate news feed an integration: a compatible-looking JSON feed is not a consumer contract. Fix: prove a published schema, a checked-in consumer, and an end-to-end build.
• Using the current site as historical evidence: live content can change. Fix: cite the dated commit or deployment run for historical claims.

See Also¶

• architecture documentation
• data serialization formats
• testing and quality
• devops cicd