The purpose-prefixed labels (hanzo-build-*, hanzo-deploy-*, hanzo-docs-build-*)
are retired in favour of the bare <os>-<arch> every runner already advertises.
They were not a capability, only a habit, and the habit cost builds: papers asked
for hanzo-build-linux-amd64, no online runner offered it, and two idle
linux-amd64 runners sat beside the queue while the build simply never ran. The
lux tree lost three days to lux-linux-amd64 the same way.
What a job is FOR is the workflow's name. runs-on is the machine it needs.
Co-authored-by: Hanzo Dev <[email protected]>
"Forge" named nothing here — Hanzo Git is the product, git.hanzo.ai is the
address. A word invented to sound generic makes a reader look for a system that
does not exist.
Co-authored-by: Hanzo Dev <[email protected]>
A registry token held as a forge secret is a second home for one thing, and the
one that rots unwatched. Only the KMS machine identity stays on the forge; the
token is read at publish time, from the surface every other Hanzo credential
already comes from.
Co-authored-by: Hanzo Dev <[email protected]>
One family. Font stacks name Zen and fall back to the native faces, tokens
name the role rather than a face, and the packages that used to supply a
face now point at @hanzo/font.
Self-hosted @font-face blocks are removed rather than renamed: rewriting the
family in one would leave a src pointing at a file this repo no longer ships.
@hanzo/font carries the binaries and declares the faces, so the local copies
go with the declaration that used them.
Comments naming a face we no longer use are deleted, not reworded.
runs-on was a bare scalar. Jobs written that way queue and are never
picked up — link and quest have waited since 10 August, painter since the
5th, none of them with a single success — while repos writing the same
label as a sequence drain within seconds of a push on the same fleet.
Same label, same runners, different shape. It fails silently: nothing errors,
the job simply never starts, so the lane looks configured and does nothing.
Both releases so far went to npmjs from a developer machine. hanzoai/ui states
the rule plainly -- publish.yml on a version change is the only thing allowed to
reach npmjs -- and this repo had no way to honour it because it had neither a
gate nor a workflow.
The publish job asks the REGISTRY whether it is behind, rather than reading the
previous commit or filtering on paths. Both of those guess, and hanzoai/ui lost
a release to each: a path gate that could not re-run the lockfile fix that
repaired it, and a merge whose first parent already carried the bump. Forward
only, so a revert cannot walk the registry backwards.
The gate is `node --check`, and that is the honest whole of it. There is no
build here: src/control.js is served to a browser byte-for-byte, so a syntax
error reaches every embedding site at once and reads as a widget that silently
never mounts.
Co-authored-by: Hanzo Dev <[email protected]>
The glyph is the assistant's now and the header says the name instead, so a
reader meets one shape in one corner rather than the same shape in two places
meaning two things: ask here, go home there.
Same five paths @hanzogui/shell draws, so the corner and the chrome cannot
drift into two silhouettes.
Co-authored-by: Hanzo Dev <[email protected]>
Rollout needs numbers, and the obvious way to get them is the defect this
codebase already has a scar from: a second client posting to /v1/event counted
every pageview twice.
A script tag cannot share the page's @hanzo/event client -- that client is a
module the app holds, with no global -- so coordination is not available. What
is available is not overlapping: three events named for the widget, emitted by
nothing else. No shared transport, no reconciliation, and a double count is not
expressible rather than merely avoided.
Same door, key and opt-out as the recordings, so a reader who declined
measurement is not measured here either.
Co-authored-by: Hanzo Dev <[email protected]>
hanzo.app grew the Help and preferences panes into its own copy after this
package took its snapshot, so the two disagreed within the hour -- which is the
argument for hanzo.app consuming the package rather than carrying the file.
Synced. The panel now shows Appearance, Language and Help beside the
contextual action, which is the structure the README already described.
Co-authored-by: Hanzo Dev <[email protected]>
One name per thing, in the repo that owns the thing, so the apps, the docs and a
customer's site are not each deciding what to call it.
Two rules carry the weight. A visitor never sees the word Hanzo: the product name
belongs to the docs, the package and the deployment setting, and the panel says
Controls so it reads as part of whatever site it is on. And permission REPLACES
the contextual slot rather than adding to it, so an editor never sees both
Suggest an edit and Edit page.
Report a problem is deliberately absent. It is the same lane as Suggest an edit
wearing a narrower hat, and two doors for one intent means the reports land in
the wrong queue about half the time. Help is one door out to support and docs.
Admin stays a different surface. Organization and project configuration, security,
billing and members are not in here.
Co-authored-by: Hanzo Dev <[email protected]>
Lifted from hanzo.app/public/edit.js, unchanged. It was already the thing every
surface needs: dependency-free vanilla JS in a shadow root, so it renders the
same on a Next export, a Vite app and a Django-served React app, and neither
side can restyle the other by accident. It reads its configuration from the
page's own meta tags, so a static export can configure it. It floats in the
corner, or docks into a slot the host names and watches for that slot to appear
rather than querying once, because a framework mounts it after the script runs.
BASE is the origin the script was served from, so the backend follows the host
and there is nothing to configure: served from api.hanzo.ai it calls
api.hanzo.ai.
Edit and suggest are the panes that exist. Appearance, language and help are
renders into the same panel, not widgets of their own.
Co-authored-by: Hanzo Dev <[email protected]>
zeekayandHanzo Dev