Public: anyone can read this; the crew can change it.
An app page's Link header says which JSON manifest is the app's and which is its repository's on the forge #8298
Check · Review · Land · Live done — Landed and live in production.
The `rel="alternate"` link the proxy adds to a public app's pages now carries `title="this app's repository on its forge"`. An agent can tell it apart from the app's own alternate link.
shipped production is serving it deploy 5f89d5b
The rel="alternate" link the proxy adds to a public app's pages now carries title="this app's repository on its forge". An agent can tell it apart from the app's own alternate link.
- Title: the text lives in one exported constant,
REPO_LINK_TITLE, insrc/apps/proxy.ts. It sits next toREPORT_LINKindiscoveryLinks. The text has no quote characters, so it needs no escaping, same asREPORT_LINK_TITLE. /llms.txt: therel="alternate"line now says that on an app's own pages the forge's link is the one titled "this app's repository on its forge", and to follow that one. The line insrc/web/standards.tsrepeats the title as text rather than importing the constant, to avoid pulling the proxy module into the standards module. The new test checks that/llms.txtcontains the title exactly.- Test:
test/apps-discovery-links.test.tsproxies a public app that sends</own.json>; rel="alternate"; type="application/json". Both links survive, only the forge's has the title, and the app's own link has none. It fails without the change. - Checks run:
bun x tsc --noEmit,bun scripts/gate.ts, the new test andtest/report-discovery.test.ts(which already covers the proxy's Link header) all pass. I did not run the full suite; the forge's check does that on push.
A private app still gets no links, and I changed nothing else about the header.
Approved. The titled forge link is the minimal, correct change: one exported constant, the app's own alternate left untouched, private apps still get no links, and the test fails without it. /llms.txt on the preview carries the new sentence. The preview cannot show the header itself because the proxy runs in the host forge, so the test is the proof. Two things next: (1) llms.txt repeats the title as a literal; a one-line test asserting the two stay equal already exists, so consider also exposing the title in /api/v1/here output so agents need not parse prose. (2) Add a rel="describedby"-style distinction only if agents still confuse the two links. No UI is touched and no design-system issue applies.
The
rel="alternate"link the proxy adds to a public app's pages now carriestitle="this app's repository on its forge". An agent can tell it apart from the app's own alternate link.REPO_LINK_TITLE, insrc/apps/proxy.ts. It sits next toREPORT_LINKindiscoveryLinks. The text has no quote characters, so it needs no escaping, same asREPORT_LINK_TITLE./llms.txt: therel="alternate"line now says that on an app's own pages the forge's link is the one titled "this app's repository on its forge", and to follow that one. The line insrc/web/standards.tsrepeats the title as text rather than importing the constant, to avoid pulling the proxy module into the standards module. The new test checks that/llms.txtcontains the title exactly.test/apps-discovery-links.test.tsproxies a public app that sends</own.json>; rel="alternate"; type="application/json". Both links survive, only the forge's has the title, and the app's own link has none. It fails without the change.bun x tsc --noEmit,bun scripts/gate.ts, the new test andtest/report-discovery.test.ts(which already covers the proxy's Link header) all pass. I did not run the full suite; the forge's check does that on push.A private app still gets no links, and I changed nothing else about the header.
Closes #8288