meshgen,
a content network with revenue gravity.

meshgen is a deliberate cross-linking topology, not a single property. Six nodes (niche authority blog, newsletter, comparison/review hub, digital products, free AI ROI calculator, social bridge) hand off audience and intent in defined directions. The doctrine, the architecture, and the editorial Definition of Done are scoped to docs/*.md --- one file per concern, no duplication.

ITech scope

• Monorepo by node: nodes/<slug>/ for per-node assets, shared/ for cross-node libraries, docs/ for network-level doctrine. The split is enforced by convention rather than tooling — the goal is that any node can be lifted out into its own repo without rework if the topology shifts.
• Live execution state is queried, never duplicated. configure_site.py status, the WordPress REST API, and git log are the source of truth for what is actually deployed. Markdown READMEs describe intent; runtime is consulted for fact, which prevents the "docs say one thing, prod does another" failure mode that tends to land in week three of a content network.
• Article drafts live at nodes/<slug>/articles/NN-slug.md, where the leading number is the editorial sequence and is never reused. Per-node secrets land in .env at the node root and are gitignored; the deploy script reads them at upload time, so a leaked secret in git history is structurally hard to produce.
• Generated images are gitignored. Featured images and Pinterest pins are regenerated on demand by shared/scripts/gen_featured_image.py and gen_pin.py, both of which call into the local flux worker via MasterAgent — so the pixel data never enters the repo and the prompt + seed pair is what actually persists.
• Schema discipline lives in shared/lib/db.py. WordPress’s default schema is left intact; meshgen-specific metadata (campaign id, cross-link source, image-prompt seed) lives in postmeta with a meshgen_ prefix so a future detach-and-migrate is a SELECT away.

IINetwork topology

The mesh is six nodes, each independently publishable, each with a defined role. Cross-node hand-offs are deliberate — routed for revenue rather than placed by a plugin — so the audience and intent move between nodes the way the editorial plan says they should:

• N1 → N2 — content upgrades and email capture. The blog earns the visit; the newsletter earns the relationship.
• N1 → N3 — product mentions feed the comparison / review hub. A "what to use" question on the blog routes to the structured comparison without forcing the reader to re-search.
• N1 → N4 — resource recommendations. Long-form articles point to the digital products node when the reader has expressed buying intent in the article context.
• N3 → N1 — educational deep-links from review pages. The review hub assumes the reader knows the category; when they don’t, it links them back to the foundational article.
• N5 → N3 — the free AI ROI calculator routes its results to specific tools in the review hub. The calculator is a lead magnet by structure, not by gating.
• N6 → N1/N2/N3 — social bridges (Pinterest, X, LinkedIn) feed traffic upward into the blog, the newsletter, and the review hub. The social node is never an endpoint; its job is to surface the rest of the mesh.

The hand-coded part is the link itself. When writing an article or building a page, the appropriate cross-node link is placed by hand from a template, not synthesized by a plugin — so revenue is never stranded at one node and a refactor of the topology is a search-and-replace, not a database migration.

IIIFailure isolation

The hard constraint is that no node may be a single point of failure for any other. If the social property goes dark for a week, the blog and the newsletter keep publishing without it. If the review hub’s WordPress install needs a maintenance window, the calculator on N5 keeps returning answers, just without the upsell link. Every node is dual-format (web + RSS) and the publishing pipeline does not assume web is canonical — an RSS subscriber who never visits the site still receives the article, the cross-link, and the byline.

Anchor-as-hub is a working model, not a final one. The next ratchet is anchor-of-anchors: two or three meshes sharing a topology so the failure of any single anchor is recoverable without a republish. That is on the roadmap, not in the running system.

IVVoice

Articles publish under the Marcus Hale byline. The voice guide is authoritative, data-driven, direct: specific numbers over adjectives, first-person only on testing experience (never on opinion), and a banned-vocabulary list that excludes "mind-blowing", "game-changer", "revolutionary", "unleash", "leverage", and a longer tail in docs/voice.md. The byline is a pen name, not a synthetic persona — every article has a single human author who is accountable for it, and the editorial stance is that an LLM may copy-edit a draft but may not generate one from a prompt.

VSurface

The mesh is not a CMS. Each node is an independently-publishable property — blog, newsletter, reviews catalog, products, tool, and social presence — that links back to and from the anchor (searchengineu.com) under a single editorial voice. Authoring is markdown plus the local image worker (flux) for featured images and Pinterest pins, which means the pixel data and the prompts that produced it live on the same disk as the node that publishes them. Cross-linking between nodes is generated from a routing template rather than hand-maintained, which keeps the mesh shape honest as nodes evolve and prevents revenue from getting stranded at a node where a rename or restructure broke the inbound link. As of this writing, only the anchor is built; the other five are planned, named, and scoped — not running.

VIConstraints

The hard constraint is that no node may be a single point of failure for any other. If the social property goes dark for a week, the rest of the mesh keeps publishing without it; if WordPress on the anchor needs a maintenance window, the calculator on N5 keeps returning answers, just without the upsell link. Anchor-as-hub is a working topology, not a final one. The next ratchet is anchor-of-anchors, where two or three meshes share a routing layer so the failure of any single anchor is recoverable without a republish — the same topology pattern at one scale up. Every node is dual-format (web + RSS) and the publishing pipeline does not assume web is canonical, because an RSS subscriber who never visits the site still receives the article, the cross-link, and the byline.