Context Rules Need a Runtime

The day started with git clone

At 4:10 PM, I asked Cursor to do something ordinary:

That put context-infrastructure inside the Dahui repo. On the surface, it was just another directory. The real question came 49 minutes later: would Cursor automatically use context-infrastructure/rules/USER.md when replying?

The answer was clear: not in the current setup.

The important part was where USER.md lived. As a normal Markdown file, context-infrastructure/rules/USER.md sits in the repo. Opening it, mentioning it with @, or keeping it visible in the file tree only makes the file available. It starts to shape the agent when I explicitly reference it, or when I place it somewhere Cursor loads as a rule, such as .cursor/rules/*.mdc.

That clarified an easy confusion: a context file is material. For material to change behavior, it has to enter the runtime.

COMMUNICATION.md became a writing constraint

At 5:10 PM, the question moved to blog writing:

COMMUNICATION.md is specific. It asks for restrained prose, fewer grand claims, fewer casual metaphors, backticks around technical identifiers, light connective tissue in Chinese paragraphs, and link text that carries meaning. It turns "write more naturally" into a style guide with checks.

The agent then searched for the existing blog program. It found several facts:

• Blog posts already live in src/content/posts/*.mdx.
• The site reads them through src/lib/posts.ts.
• Several posts have already been published.
• docs/architecture_v2.md mentions authoring CLIs such as scripts/new-post.ts and scripts/translate-post.ts.

Then the agent made a claim that was too broad: the blog writing design existed, but the scripts had not been implemented. That needed correction a few minutes later.

The human correction mattered

At 5:14 PM, I asked:

That was the most useful calibration point in the session.

The posts already exist, so the content workflow is real. MDX, frontmatter, WorkflowNote, <Zh> / <En>, and bilingual post structure are already accepted by the project and rendered by the site. Describing the whole writing workflow as unimplemented would mislead the reader into thinking the existing posts lack a real process.

The narrower and more accurate claim is:

That sounds like wording, but it is really engineering judgment. A content workflow and an authoring CLI are different layers. The first proves that posts can be written and published. The second makes the step from conversation to draft more repeatable.

What the authoring CLI actually does

At 5:16 PM, I asked what scripts/new-post.ts and scripts/translate-post.ts were supposed to do.

The answer can be reduced to two functions.

new-post turns a Cursor or AI conversation into the starting point for a post. It creates src/content/posts/<slug>.mdx, fills in frontmatter, WorkflowNote, <Zh> / <En> sections, and produces a drafting prompt that includes COMMUNICATION.md.

translate-post reads the <Zh> content from an existing MDX file and produces a prompt for the English <En> version. Including COMMUNICATION.md here preserves the original draft's restraint, specificity, and low tolerance for empty meta-commentary.

These scripts are not runtime features for readers. Readers care that src/content/posts/*.mdx renders correctly on the website. The authoring CLI serves the writer. It is especially useful for a session like today, where I do not want to restate the blog format, style guide, bilingual structure, and self-checks every time I start a new post.

The actual lesson

The same pattern showed up several times today: a rule file sitting in the repo has limited effect.

USER.md shapes the agent after it is read or placed in Cursor's rule-loading path. COMMUNICATION.md shapes a post after it enters the writing prompt. new-post and translate-post, as described in docs/architecture_v2.md, reduce future friction after they become commands that the writer can run.

So context-infrastructure is reusable material: user preferences, communication style, workflows, and writing standards. The real work is connecting that material to the places that actually execute.

The lesson from May 11 is short:

Putting rule files in a repo only archives the material.
To affect the agent, a rule must enter the agent context.
To affect a blog post, a rule must enter the writing program or prompt.
To affect a workflow, a rule must sit on the path that humans and AI repeatedly travel.