coilysiren/website

Watch

Project pages: hub-and-spoke on coilysiren.me, not four standalone sites #133

New issue

Open

opened 2026-08-27 03:25:17 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-08-27 03:25:17 +00:00

Collaborator

Reads as a companion to coilysiren/inbox#407, which owns the post program. Neither works as well alone, and the last section explains why.

The decision: subdirectory pages, not standalone sites

coilysiren.me/projects/<name>/. Four pages. No new domains, no subdomains.

Kai raised standalone sites per project. Recommending against, on four grounds.

Authority does not split well when there is not much of it. Subdirectories feed all traffic, backlinks, and authority into one domain, while a subdomain or separate domain is treated as a separate site that has to build authority from zero. coilysiren.me has exactly one small pool of authority, freshly verified in Search Console and Bing, with a corpus of two posts that already surface unprompted. Splitting that four ways is the worst available move for the stated goal.

The stated goal is inbound to Kai, not to the projects. #407 establishes the site as the ungated surface that accrues authority while LinkedIn waits on the name change. Four product domains build four product entities. The thing that needs to rank is a person.

These are evidence, not products with users. The standalone-domain pattern is real and works, and the reference case shows what it costs: Simon Willison runs datasette.io as its own site for a project with a user base, a hosted commercial product, and sponsorship, while everything else on simonwillison.net lives as tag feeds. A project earns its own domain when it has users to serve and docs to host. None of these four has that yet, and the audience for all four is a hiring manager.

Capacity is a confirmed constraint. Four sites is four deploys, four metadata surfaces, four sitemaps, four drift surfaces. 2026-08-24 was spent repairing drift across the three surfaces that already exist.

Graduation path, so this is not a door closing. If a project later earns a real user base, point its own domain at the section and 301 the subdirectory. That is a cheap, standard move and it is strictly easier than merging four scattered domains back together.

The defect this fixes

Verified on the live homepage 2026-08-25. All four showcase cards link directly to github.com. The homepage's strongest content sends every interested visitor off the domain at the exact moment of highest interest.

That is the whole argument for project pages in one line. Today the site's job ends at "here is a card, now go read a README on someone else's domain." GitHub should be where a reader goes after the case is made, not instead of it.

Function, and how it fits the existing program

#407 establishes topic clusters as posts, buyer-framed, low cadence, extraction rather than invention. That is the spoke layer. It has no hub.

Project page = hub. Evergreen, stable, one per entity. It is what a name or product search lands on and what an answer engine cites.
Post = spoke. A problem named in the reader's terms with the cost attached, per #407.
Every spoke links to its hub. The hub links its spokes.

This is the standard shape for topic authority and it costs nothing extra, because #407 is already committing to the posts. Right now those posts would have nowhere to point.

Second function: the hub is the page Kai controls. A GitHub README builds GitHub's entity. A project page with SoftwareSourceCode markup, internal links, and a canonical on her own domain builds hers.

Form: the page structure

Eight sections. Order matters and is not negotiable, because it is the buyer-framing order from #407, which is a problem the reader already has, named in their terms, with the cost of leaving it unfixed attached.

Mark, name, and the one-line claim. The claim is the repository's canonical description verbatim, per coilysiren/inbox#397. Never re-invented for this page.
The problem, and what it costs to leave alone. The hero. Written for someone who owns the problem, not someone shopping for a library. This is the section that decides whether the page reaches buyers or practitioners.
What it does about it. The mechanism at one level of depth. The proof copy in src/data/projects.js is already exactly this and is already Kai-authored.
What it looks like in use. One real artifact: a guardfile, a command, a refusal, a composed bundle. This is where these four projects are unusually strong, because the policy artifacts are short and readable, and a reader who sees one understands the product immediately.
What it does not do. Scope limits and honest non-goals. Converts buyers better than more features do, and it is Kai's register anyway.
Status and evidence. Release tag, install line, platforms, what is actually deployed. umbra at v0.126.0 and agent-compose at v1.32.0 have tagged releases. mcp-beaver and sirens-echo do not, and the page should say what is true rather than imply parity.
Related writing. The spoke links. Empty at first and fills as #407 produces posts.
Repository and docs. Last. Not first.

Source material, because this is extraction not invention

Confirmed present 2026-08-25. 573KB of documentation across the four repositories, and every one has a FEATURES.md.

umbra - README 3.4KB, docs 21 entries 57.9KB, v0.126.0
mcp-beaver - README 6.1KB, docs 21 entries 41.6KB, no release
agent-compose - README 4.9KB, docs 40 entries 178.8KB, v1.32.0
sirens-echo - README 4.6KB, docs 41 entries 295.5KB, no release

Plus the four published banner claims, the four proof lines in projects.js, and the lore-method-* entries. Sections 1, 3, 6 and 8 are close to mechanical. Sections 2, 4 and 5 need writing, and that is Developer Advocate work.

The sync trap, named so it is designed out

Adding four pages adds four surfaces that can drift, which is precisely the failure repaired across the resume, the profile README and the org profiles on 2026-08-24.

The rule: a project page never restates a fact that has a canonical home. The one-line claim comes from the repository description. The release tag and install line come from the release. Anything hand-written on the page must be content that exists nowhere else, which is sections 2, 4 and 5. If a page and a repository disagree about what a project is, the repository wins and the page is the bug.

Technical function

SoftwareSourceCode or SoftwareApplication JSON-LD per page, with author pointing at the existing Person entity on the homepage.
Every project page in the sitemap. coilysiren/website#125 is already fixing sitemap derivation for the post layer, and this must not repeat that failure.
The homepage showcase cards repoint at the project pages. The GitHub link moves onto the project page.
llms.txt gains the four pages. It currently declares four public pages and mentions no projects at all.

Not in scope

Visual design. Delphi's, and this issue deliberately specifies structure and content rather than layout.
Build and routing. Platform work, an Eleventy collection plus a template.
The marks. coilysiren/inbox#406 and its children. These pages composite whatever that lands, and must not block on it, since a page with the current mark is better than no page.
Post content. #407.
Whether to do this at all. Kai decided. Not reopened here.

Done means

Four pages live at coilysiren.me/projects/<name>/
Homepage cards point at them rather than at github.com
Each page carries all eight sections, with section 7 allowed to be empty
No page restates a fact with a canonical home elsewhere
JSON-LD per page, linked to the existing Person
All four in the sitemap and in llms.txt
Baseline recorded in Search Console before publication, so the cluster can be told working from dead

Kai decided on 2026-08-25 that the site is worth investing in and tasked the Developer Advocate seat with the form and function. The investment question was hers and is settled, so this issue covers structure and content only. Reads as a companion to `coilysiren/inbox#407`, which owns the post program. Neither works as well alone, and the last section explains why. ## The decision: subdirectory pages, not standalone sites **`coilysiren.me/projects/<name>/`. Four pages. No new domains, no subdomains.** Kai raised standalone sites per project. Recommending against, on four grounds. **Authority does not split well when there is not much of it.** Subdirectories feed all traffic, backlinks, and authority into one domain, while a subdomain or separate domain is treated as a separate site that has to build authority from zero. `coilysiren.me` has exactly one small pool of authority, freshly verified in Search Console and Bing, with a corpus of two posts that already surface unprompted. Splitting that four ways is the worst available move for the stated goal. **The stated goal is inbound to Kai, not to the projects.** `#407` establishes the site as the ungated surface that accrues authority while LinkedIn waits on the name change. Four product domains build four product entities. The thing that needs to rank is a person. **These are evidence, not products with users.** The standalone-domain pattern is real and works, and the reference case shows what it costs: Simon Willison runs `datasette.io` as its own site for a project with a user base, a hosted commercial product, and sponsorship, while everything else on `simonwillison.net` lives as tag feeds. A project earns its own domain when it has users to serve and docs to host. None of these four has that yet, and the audience for all four is a hiring manager. **Capacity is a confirmed constraint.** Four sites is four deploys, four metadata surfaces, four sitemaps, four drift surfaces. 2026-08-24 was spent repairing drift across the three surfaces that already exist. **Graduation path, so this is not a door closing.** If a project later earns a real user base, point its own domain at the section and 301 the subdirectory. That is a cheap, standard move and it is strictly easier than merging four scattered domains back together. ## The defect this fixes Verified on the live homepage 2026-08-25. **All four showcase cards link directly to `github.com`.** The homepage's strongest content sends every interested visitor off the domain at the exact moment of highest interest. That is the whole argument for project pages in one line. Today the site's job ends at "here is a card, now go read a README on someone else's domain." GitHub should be where a reader goes **after** the case is made, not instead of it. ## Function, and how it fits the existing program `#407` establishes topic clusters as posts, buyer-framed, low cadence, extraction rather than invention. That is the **spoke** layer. It has no **hub**. * **Project page = hub.** Evergreen, stable, one per entity. It is what a name or product search lands on and what an answer engine cites. * **Post = spoke.** A problem named in the reader's terms with the cost attached, per `#407`. * **Every spoke links to its hub. The hub links its spokes.** This is the standard shape for topic authority and it costs nothing extra, because `#407` is already committing to the posts. Right now those posts would have nowhere to point. Second function: the hub is the page Kai controls. A GitHub README builds GitHub's entity. A project page with `SoftwareSourceCode` markup, internal links, and a canonical on her own domain builds hers. ## Form: the page structure Eight sections. Order matters and is not negotiable, because it is the buyer-framing order from `#407`, which is a problem the reader already has, named in their terms, with the cost of leaving it unfixed attached. 1. **Mark, name, and the one-line claim.** The claim is the repository's canonical description verbatim, per `coilysiren/inbox#397`. Never re-invented for this page. 2. **The problem, and what it costs to leave alone.** The hero. Written for someone who owns the problem, not someone shopping for a library. This is the section that decides whether the page reaches buyers or practitioners. 3. **What it does about it.** The mechanism at one level of depth. The `proof` copy in `src/data/projects.js` is already exactly this and is already Kai-authored. 4. **What it looks like in use.** One real artifact: a guardfile, a command, a refusal, a composed bundle. This is where these four projects are unusually strong, because the policy artifacts are short and readable, and a reader who sees one understands the product immediately. 5. **What it does not do.** Scope limits and honest non-goals. Converts buyers better than more features do, and it is Kai's register anyway. 6. **Status and evidence.** Release tag, install line, platforms, what is actually deployed. `umbra` at `v0.126.0` and `agent-compose` at `v1.32.0` have tagged releases. `mcp-beaver` and `sirens-echo` do not, and the page should say what is true rather than imply parity. 7. **Related writing.** The spoke links. Empty at first and fills as `#407` produces posts. 8. **Repository and docs.** Last. Not first. ## Source material, because this is extraction not invention Confirmed present 2026-08-25. **573KB of documentation across the four repositories, and every one has a `FEATURES.md`.** * `umbra` - README 3.4KB, docs 21 entries 57.9KB, `v0.126.0` * `mcp-beaver` - README 6.1KB, docs 21 entries 41.6KB, no release * `agent-compose` - README 4.9KB, docs 40 entries 178.8KB, `v1.32.0` * `sirens-echo` - README 4.6KB, docs 41 entries 295.5KB, no release Plus the four published banner claims, the four `proof` lines in `projects.js`, and the `lore-method-*` entries. Sections 1, 3, 6 and 8 are close to mechanical. Sections 2, 4 and 5 need writing, and that is Developer Advocate work. ## The sync trap, named so it is designed out Adding four pages adds four surfaces that can drift, which is precisely the failure repaired across the resume, the profile README and the org profiles on 2026-08-24. **The rule: a project page never restates a fact that has a canonical home.** The one-line claim comes from the repository description. The release tag and install line come from the release. Anything hand-written on the page must be content that exists nowhere else, which is sections 2, 4 and 5. If a page and a repository disagree about what a project is, the repository wins and the page is the bug. ## Technical function * `SoftwareSourceCode` or `SoftwareApplication` JSON-LD per page, with `author` pointing at the existing `Person` entity on the homepage. * Every project page in the sitemap. `coilysiren/website#125` is already fixing sitemap derivation for the post layer, and this must not repeat that failure. * The homepage showcase cards repoint at the project pages. The GitHub link moves onto the project page. * `llms.txt` gains the four pages. It currently declares four public pages and mentions no projects at all. ## Not in scope * **Visual design.** Delphi's, and this issue deliberately specifies structure and content rather than layout. * **Build and routing.** Platform work, an Eleventy collection plus a template. * **The marks.** `coilysiren/inbox#406` and its children. These pages composite whatever that lands, and must not block on it, since a page with the current mark is better than no page. * **Post content.** `#407`. * **Whether to do this at all.** Kai decided. Not reopened here. ## Done means - [ ] Four pages live at `coilysiren.me/projects/<name>/` - [ ] Homepage cards point at them rather than at `github.com` - [ ] Each page carries all eight sections, with section 7 allowed to be empty - [ ] No page restates a fact with a canonical home elsewhere - [ ] JSON-LD per page, linked to the existing `Person` - [ ] All four in the sitemap and in `llms.txt` - [x] Baseline recorded in Search Console before publication, so the cluster can be told working from dead

coilyco-ops referenced this issue from a commit

2026-08-27 07:20:17 +00:00

feat: sync the project docs mount instead of hand-vendoring it

coilyco-ops referenced this issue

2026-08-27 07:39:54 +00:00

Sync the project docs mount instead of hand-vendoring it #135

coilyco-ops commented

2026-08-27 08:00:49 +00:00

Author

Collaborator

The docs cluster published ahead of this issue's baseline box, on Kai's explicit call (website#135). Recording what the baseline should capture, and why today is the last clean moment to take it.

22 pages went live at /projects/umbra/docs/ with canonical, per-page descriptions, TechArticle and BreadcrumbList. The sitemap went from 11 URLs to 33 and is already serving. Google has not crawled them yet, so an indexing snapshot taken now is still effectively pre-cluster. That stops being true within days.

What the baseline will show, and what it means

The property was verified around 2026-08-25 per this issue. Search Console does not backfill, so Performance is nearly empty by construction rather than by failure. Expect low-double-digit impressions, clicks at or near zero, brand-dominated queries, and whatever non-brand impressions the Azure OpenAI Terraform post draws. At that volume average position is noise.

The report worth recording is Pages, not Performance:

Total indexed, which is likely under the 11 URLs that were in the sitemap.
Discovered - currently not indexed for most of the rest, which is ordinary for a young domain rather than a defect.
Excluded by 'noindex' tag for /cool-people/ and the two dark posts. Record that those are deliberate, or a later reader files it as drift.

The row that decides whether this worked

Duplicate, Google chose different canonical than user and Alternate page with proper canonical tag.

The 21 vendored pages are byte-identical to copies already crawlable at forgejo.coilysiren.me and at github.com, both stronger domains. Duplicate content across domains is a filter rather than a penalty: one copy is picked and the others are dropped from the result for a query. On identical body text the pick usually favours the stronger host.

So the cluster's success condition is not impressions. It is whether those 22 URLs appear as indexed or as duplicates-with-another-canonical in six to eight weeks. If they land in the duplicate rows, more metadata will not fix it and the answer is to make this copy less identical to the markdown. That is a Developer Advocate question about the frame, not a platform one.

Capture list

Date, total indexed with the full breakdown by reason, Performance totals over a fixed 28-day window, the query and page lists however short, and the same from Bing Webmaster Tools. Screenshots suffice. The point is a timestamped record, not a dataset.

Discovery lands in days, indexing over two to six weeks, and the comparison is only readable at roughly eight weeks.

**The docs cluster published ahead of this issue's baseline box, on Kai's explicit call (website#135). Recording what the baseline should capture, and why today is the last clean moment to take it.** 22 pages went live at `/projects/umbra/docs/` with canonical, per-page descriptions, `TechArticle` and `BreadcrumbList`. The sitemap went from 11 URLs to 33 and is already serving. Google has not crawled them yet, so an indexing snapshot taken now is still effectively pre-cluster. That stops being true within days. ## What the baseline will show, and what it means The property was verified around 2026-08-25 per this issue. Search Console does not backfill, so **Performance is nearly empty by construction** rather than by failure. Expect low-double-digit impressions, clicks at or near zero, brand-dominated queries, and whatever non-brand impressions the Azure OpenAI Terraform post draws. At that volume average position is noise. The report worth recording is **Pages**, not Performance: * Total indexed, which is likely under the 11 URLs that were in the sitemap. * `Discovered - currently not indexed` for most of the rest, which is ordinary for a young domain rather than a defect. * `Excluded by 'noindex' tag` for `/cool-people/` and the two dark posts. **Record that those are deliberate**, or a later reader files it as drift. ## The row that decides whether this worked `Duplicate, Google chose different canonical than user` and `Alternate page with proper canonical tag`. The 21 vendored pages are byte-identical to copies already crawlable at `forgejo.coilysiren.me` and at `github.com`, both stronger domains. Duplicate content across domains is a filter rather than a penalty: one copy is picked and the others are dropped from the result for a query. On identical body text the pick usually favours the stronger host. So the cluster's success condition is not impressions. It is whether those 22 URLs appear as indexed or as duplicates-with-another-canonical in six to eight weeks. If they land in the duplicate rows, more metadata will not fix it and the answer is to make this copy less identical to the markdown. That is a Developer Advocate question about the frame, not a platform one. ## Capture list Date, total indexed with the full breakdown by reason, Performance totals over a fixed 28-day window, the query and page lists however short, and the same from Bing Webmaster Tools. Screenshots suffice. The point is a timestamped record, not a dataset. Discovery lands in days, indexing over two to six weeks, and the comparison is only readable at roughly eight weeks.

coilyco-ops commented

2026-08-27 08:05:08 +00:00

Author

Collaborator

Baseline recorded 2026-08-27: 14 impressions over 90 days, clicks at or near zero.

Kai read it off Search Console directly. Correcting my previous comment: the property carries three months of history rather than the two days this issue's "freshly verified" line implied, so the zero is the real number rather than an artifact of the verification date. Better evidence for the same conclusion.

That is a clean baseline. Nothing to protect, nothing to disentangle, and any signal after this is attributable.

The success metric stands as stated: not impressions, but whether the 22 docs URLs reach indexed in the Pages report over the next six to eight weeks. Impressions cannot move before that, and the duplicate-canonical rows are where they land if the GitHub copy wins the pick.

Worth saying plainly against the maximum-SEO goal: the metadata work is finished and it is not the lever. Reference documentation serves readers who already found the project. Inbound to a person comes from the post program in coilysiren/inbox#407 and from links pointing in, which is Developer Advocate and Portfolio Director work rather than anything else the platform seat can add here.

**Baseline recorded 2026-08-27: 14 impressions over 90 days, clicks at or near zero.** Kai read it off Search Console directly. Correcting my previous comment: the property carries three months of history rather than the two days this issue's "freshly verified" line implied, so the zero is the real number rather than an artifact of the verification date. Better evidence for the same conclusion. That is a clean baseline. Nothing to protect, nothing to disentangle, and any signal after this is attributable. The success metric stands as stated: not impressions, but whether the 22 docs URLs reach **indexed** in the Pages report over the next six to eight weeks. Impressions cannot move before that, and the duplicate-canonical rows are where they land if the GitHub copy wins the pick. Worth saying plainly against the maximum-SEO goal: the metadata work is finished and it is not the lever. Reference documentation serves readers who already found the project. Inbound to a person comes from the post program in coilysiren/inbox#407 and from links pointing in, which is Developer Advocate and Portfolio Director work rather than anything else the platform seat can add here.

coilyco-ops referenced this issue

2026-08-27 08:24:29 +00:00

Write the docs manifests for agent-compose and mcp-beaver: 62 pages need a title, a shelf, and a blurb #137

coilyco-ops referenced this issue from a commit

2026-08-27 09:19:54 +00:00

feat: mount the agent-compose and mcp-beaver docs

coilyco-ops referenced this issue

2026-08-28 18:16:12 +00:00

Project pages assume they are served at the site root, which breaks under a coilyco.ai vanity proxy #138

coilyco-ops referenced this issue

2026-08-28 18:40:56 +00:00

Project pages assume they are served at the site root, which breaks under a coilyco.ai vanity proxy #138