typescript 7.0.2 is the native compiler and exports no JavaScript API, so
@glint/core cannot read it. It comes in aliased as tsgo and does the
typechecking; typescript stays on the 6 line for glint.
jsconfig.json is the only program here — it has no .ts files, and jsconfig
implies checkJs, so the check runs over the .js and .gjs the paths map. 172
diagnostics, the same set on 6.0.3 and on 7.0.2.
Co-authored-by: Hanzo Dev <[email protected]>
The committed lockfile could not be installed: it still carried a patch entry for
@ember-compat/tracked-built-ins that pnpm-workspace.yaml no longer declares, so
pnpm refused a frozen install outright, and it held typescript 5.6.3 against a
catalog that declared 7.0.2. Nothing had ever installed that pin.
typescript 7 is the native compiler and exports no JavaScript API. @glint/core
loads that API, and glint is the only thing typechecking this repo, so the
declared 7.0.2 would have taken glint out the moment anyone installed it. The
catalog holds typescript on the 6 line, and the lockfile now reproduces the
ranges around it.
Co-authored-by: Hanzo Dev <[email protected]>
A version written into a manifest is written into every manifest that wants it,
which is how eslint came to exist in a hundred and four forms across this estate
and how a package came to resolve twice at run time. The catalog moves the number
out of the manifest: a manifest names the package, the workspace names the
version.
Four are held below their latest because the newer release cannot be used, and
the reason is recorded rather than the version alone: @noble/hashes 2 renamed
every subpath the web3 stack imports, @splinetool/runtime 2 depends on a package
that was never published, @dynamic-labs 5.4.1 the same, and react-resizable-panels
3 points its types condition at the bundle.
point the registry at our verdaccio, which proxies and caches all of npm
alongside our own scoped packages. lockfiles are untouched: npm and pnpm
both honor .npmrc at fetch time, so no re-resolution is needed.
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.
The forge takes a repo's workflows from the first of its search paths that
exists, and .hanzo/workflows comes before .github/workflows. This repo has
carried .hanzo/workflows/cicd.yml since it adopted the canonical lane, so
everything under .github/workflows has been inert since that day. The run
history says the same: of eight runs, four are the live cicd lane and the other
four — linting, licenses and two stale-pr-closer — were all cancelled, queued
against ubuntu-latest and debian-12, labels no runner here answers.
So this deletes dead files rather than migrating live ones, and nothing is
revived:
- check-pr-body, labeler, stale-pr-closer and dependabot-pnpm-dedupe are
GitHub-platform automation: a dependabot body rewrite, a pull request
labeller, a stale closer, and a lockfile dedupe on branches that do not exist
here.
- linting, licenses, migration-tests and tests hold the real value, and all four
want the same harness — a discourse_test container, a bundle install of the
whole Gemfile, a pnpm install of a monorepo this size, and for the suites a
Postgres and a Redis. hanzo.yml already records why that is a harness rather
than a push gate, and this repo's gate stays what it says it is: every tracked
Ruby file parses.
- release-notes turned bin/rake release_note:generate into a step summary and an
artifact. The rake task is untouched and still runs by hand.
What goes with them, none of which has run since the lane moved: rubocop,
syntax_tree, eslint, prettier, ember template lint, stylelint, glint, the i18n
lint, the RubyGems and JS licence checks, and the rspec, qunit and migration
suites.
`ruby -c` resolves a script the way the loader does, so a first line
naming another interpreter makes it hunt for a `#!...ruby` line. Rakefile
says `#!/usr/bin/env rake`; ruby finds no ruby line and reports "no Ruby
script found in input" on a file that parses fine. That was the red.
parse_file reads the file as source, which is the fact the gate asserts,
and one interpreter replaces 5851 process spawns.
Co-authored-by: Hanzo Dev <[email protected]>
kv named the wrong server binary (kv-server, not valkey-server) and assumed a C
compiler the reusable installs only for Go callers; forum assumed a ruby the
reusable never provisions; rocm-rs left gpu-sort on, whose nested nightly
build-std step no stock runner can do; insights-rs asked for --all-features,
which selects the live-endpoint e2e feature.
Co-authored-by: Hanzo Dev <[email protected]>
github.com has no runner for hanzo-build-linux-amd64, so a caller under
.github/workflows is a gate that can never be scheduled. This is the ~7-line
caller on the plane that can (git.hanzo.ai git-runner fleet), pinned @v1.
Co-authored-by: Hanzo Dev <[email protected]>
The README was Discourse's, verbatim: their logo, their mission, their team,
their accessibility contact — and a hosting pitch linking to
discourse.org/pricing, which sent anyone landing here to a third party's
checkout. Read as ours it claims a community platform we do not run;
forum.hanzo.ai 404s and the only Hanzo commits on the fork are CI, a hero
banner and agent docs.
Now says what it is: a tracking fork of Discourse with nothing built on top,
nothing deployed, where to go for Discourse and where to go for Hanzo. Kept
the upstream dev-setup links, which are the ones that actually apply. Lineage
and GPL-2.0 attribution kept and made explicit.
Superseded: the Hanzo GitHub App pushes a webhook, so the forge tracks GitHub
without a per-repo workflow. This file called git.hanzo.ai/api/v1/.../mirror-sync
— a Gitea API for a system we no longer drive — and would sit inert in every repo.
One mechanism, in one place, instead of ~350 copies of a cron.
git.hanzo.ai mirrors this repo by PULL on a ~10-minute interval, and arcd runs
CI/CD there — so every push waited out that interval before anything built.
This asks Gitea to pull HEAD immediately.
Latency only: the repo already mirrors via the App webhook, so a missing
HANZO_GIT_TOKEN or a failed curl is non-fatal and never fails the push.
Idempotent (mirror-sync just pulls HEAD) and concurrency-coalesced.
zeekayandHanzo Dev