2026-06-19

Use Stable Project Names for Recurring HTML Workflows

A practical BinHTML rule for recurring AI-generated HTML: keep `projectName` stable, move dates to artifact titles, and preserve one handoff URL for reviewers.

developer workflowproject linksscheduled reportsHTML artifactsAI agents

Table of contents

  1. projectName is routing, not release notes
  2. Put dates on the leaves, not the container
  3. A naming pattern that survives automations and agents
  4. How to publish this cleanly with API or MCP
  5. Final thought

`projectName` is routing, not release notes

BinHTML's API docs make the contract pretty clear: projectName groups related artifacts, and Pro accounts can create one unlisted project link for that group. The MCP docs expose the same model through publish_html and publish_project.

That means projectName is not just display text. It is the grouping key behind the handoff URL.

If your daily or weekly automation publishes to Growth report 2026-06-19, then Growth report 2026-06-20, you did not create one recurring packet. You created two separate collections. The next person has to hunt for the new link again, which is exactly the problem project links are supposed to remove.

A stable project link only stays stable when the project identity stays stable.

Put dates on the leaves, not the container

Run-specific detail still matters. It just belongs lower in the structure.

Use the project for the durable thing:

  • Growth weekly report
  • Platform release packet
  • Customer rollout review
  • Model eval dashboard

Then put the changing detail on the artifacts and versions:

  • artifact title: Summary - 2026-06-19
  • artifact title: Appendix - 2026-06-19
  • version label: post-fix rerun
  • description: Covers commit abc123 after schema fix

This maps cleanly to how BinHTML already works. The API docs support version updates that keep the existing artifact share URL the same, and the Compare page is the right place to review meaningful changes before you replace what reviewers will see next.

If the date is part of the project name, every run becomes a fresh island. If the date is part of the artifact title, the project page stays useful.

A naming pattern that survives automations and agents

A good project name should answer one question fast: what recurring packet is this?

A practical default is:

  1. audience or team
  2. workflow or decision
  3. optional cadence only if it is stable

Examples:

  • Finance weekly board packet
  • Ops morning incident digest
  • Growth launch review
  • Search quality evals

Avoid putting these in projectName unless the collection is intentionally one-off:

  • calendar dates
  • commit SHAs
  • branch names
  • ticket IDs that change every run
  • words like final-final-v2

Those details make sense in artifact titles, descriptions, or source references. They do not make sense in the durable container that humans are supposed to bookmark and agents are supposed to reuse.

This is also the simplest way to keep human and agent workflows aligned. A scheduled job, a local script, and a remote MCP-connected agent can all agree on one stable projectName without needing to discover the latest timestamped variant first.

How to publish this cleanly with API or MCP

Use the API docs when the workflow is deterministic. A scheduled job already knows the stable project name, the artifact titles for this run, and whether it should create a new artifact or upload a new version.

Use the MCP docs when the agent is still assembling the packet. An MCP-capable client can expose BinHTML as a remote publishing surface, and OpenAI's MCP guide plus tools guide describe that broader tool-driven pattern.

Either way, keep the handoff model simple:

  • reuse one stable projectName
  • share the project link with reviewers when the packet has several artifacts
  • share an artifact link when one page is enough
  • run a compare step before replacing a report people already trust
  • check /pricing before you depend on shareable project links in automation

One more practical rule: the human-facing link and the owner-facing links are different jobs. Reviewers usually need the project or artifact share URL. Owners may also need management or source-download URLs from BinHTML's response, but those should stay in the operator workflow, not in the default handoff message.

Final thought

Stable review URLs come from stable project identity, not from clever naming. If you want recurring HTML workflows to feel boring in the best way, keep projectName fixed, move run metadata to the leaves, and let one BinHTML link carry the handoff.

Sources