Mesh

Mesh/ is the durable knowledge layer of a Flint. It is where a workspace turns activity into reusable understanding.

If Shards/ contains the cognitive programs an agent can execute, Mesh/ is where the outcomes of that execution are written down. Plans, tasks, reports, guides, records, and system notes all live here because Flint is built to preserve thinking, not just run commands.

What Belongs in Mesh

Put synthesized, intentional workspace knowledge in Mesh/, including:

• task and planning artifacts
• system notes that explain how the workspace works
• research notes and records
• documentation roots that become exports
• metadata notes generated to help humans and agents navigate the workspace

Keep copied external material in Sources/ and active repository checkouts in Workspace/Repos/. Mesh is for the knowledge the Flint itself owns.

The File Model

Mesh files are markdown files with YAML frontmatter. Flint's implemented tooling pays attention to:

• id
• tags
• status

Wiki links and embeds also matter because exports, linked notes, and some metadata flows rely on them.

This matters for agents because shard-based workflows usually reason over notes, not hidden databases. A Flint stays readable because the working state is mostly plain markdown.

How Mesh Supports Agent Work

Agents do not just operate in Flint; they leave durable artifacts behind in Mesh so later sessions can continue from them.

That shows up throughout the current implementation:

• flint export builds published outputs from Mesh notes
• the runtime watches Mesh/**/*.md
• sourced mesh exports are copied back into the current Flint as Mesh content under Sources/
• shard workflows generally read from or write to Mesh artifacts

In practice, Mesh is the long-term memory surface for a Flint.

Typed Files Come from Conventions and Shards

Flint itself does not hardcode one universal artifact taxonomy. Instead, shards and workspace conventions define patterns such as (Task), (Plan), (Report), (Guide), or (System).

The helper command that supports numbered typed files is:

flint helper type newnumber Task

That command scans Mesh/ and returns the next available three-digit number for the requested type.

One File Matters More Than the Others

Every serious Flint should treat this file as the session entrypoint:

Mesh/(System) Flint Init.md

This is where an agent learns what the workspace is for, what shards are installed, and which documents matter first.

Mesh and Exports

Mesh is also the publishing source for Flint's export system.

When a note should become a published export:

1. add the #export tag
2. run flint export scan
3. build the declared export with flint export build

The built output goes into Exports/, but the source of truth remains the original note graph in Mesh.

Mesh and Runtime Events

When the runtime is active, Mesh changes can trigger:

• FileChanged
• StatusChanged
• TagAdded
• TagRemoved

That makes Mesh the main event surface for hooks and automation.

Practical Mental Model

Think of Mesh as the part of Flint that turns ephemeral work into persistent workspace intelligence. Shards execute cognitive programs. Mesh stores their conclusions, decisions, and intermediate artifacts so the next agent or human can continue from something structured instead of starting over.