Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com>
Co-authored-by: Claude <noreply@anthropic.com>

Apply targeted simplifications surfaced during PR review of the
path-aware workflow gating change. Behavior is equivalent; this only
removes duplication, plugs small robustness gaps, and aligns with the
existing pinning convention.

- ci.yml: pin actions/checkout and actions/upload-artifact in
  build-validator to the SHAs already used elsewhere in the repo, so
  build-validator matches the rest of .github/workflows.
- ci.yml, construct.yml: add a workflow-level concurrency group keyed
  on workflow + ref, cancelling in-progress runs on pull_request so
  rapid force-pushes don't pile up superseded classifier runners.
- preview.yml: guard 'git rev-parse "${sha}^1"' against root /
  orphan commits — fall back to source=true so we never silently
  skip a real publish on the very first commit of a branch.
- preview.yml: drop redundant 'repository: jackin-project/jackin'
  from both checkouts (the default repository is already this repo).
- preview.yml: in publish-preview, drop the duplicated
  'Resolve source SHA' step and read the SHA from the
  source-changed job output instead. The publish-preview 'if:'
  guard is also reduced to just the source flag because
  source-changed already enforces the workflow_dispatch /
  workflow_run gating, and 'needs: source-changed' propagates that
  skip downstream.

Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com>
Co-authored-by: Claude <noreply@anthropic.com>

Add 'workflow_dispatch:' to the CI workflow's triggers so a maintainer
can manually re-run the Rust suite on demand. The other three workflows
(construct.yml, docs.yml, preview.yml) already accept workflow_dispatch
and short-circuit their classifier output to true so the heavy jobs run
unconditionally; ci.yml was the outlier.

Mirror the same pattern here:

- Declare 'workflow_dispatch' on the 'on:' block.
- Short-circuit the 'changes' classifier on workflow_dispatch by
  emitting 'rust=true' before any range-based diff. A manual run is an
  explicit operator action — it should never be filtered by the
  changed-paths heuristic.
- Extend the 'build-validator' job's gate so it also runs on
  workflow_dispatch. The previous gate restricted it to push-to-main
  with Rust changes, which meant a maintainer could not rebuild
  release validator artifacts without a Rust-touching commit landing
  on main first.

Production-facing branch restrictions in the other workflows
(deploy on docs.yml, publish-manifest on construct.yml, source-changed
on preview.yml all gated to main) are intentional safety rails and
remain unchanged.

Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com>
Co-authored-by: Claude <noreply@anthropic.com>

Address review-time silent-failure findings on the path-aware gating
PR. The previous classifier swallowed network and command failures
behind '|| true' / unhandled stderr, and the rationale comments
contained a wording bug.

preview.yml — distinguish curl failure from a legitimately empty
formula response. The new shape captures the curl exit explicitly:

  - On a real fetch error (DNS, TLS, 5xx, repo rename, etc.) emit
    '::warning::' and fall open with source=true.
  - On HTTP 200 with body that does not match the strict 40-hex-char
    URL regex (captive portal, 404 page returning 200 etc.) treat
    as 'no prior preview' and fall open silently.

The strict 40-hex-char regex is now load-bearing safety net for the
captive-portal case; an inline comment calls that out so a future
maintainer cannot relax the regex thinking it is incidental.

preview.yml — capture 'git diff' stderr to a separate file rather
than into the success-path variable. A benign ambiguous-ref warning
written to stderr while exit is 0 would otherwise be processed by
the case statement; the new shape only reads stderr on the failure
branch when it appears in the warning log.

preview.yml — add an explicit '[ -z "$path" ] && continue' guard
inside the diff-walking loop. The trailing-newline empty iteration is
harmless today (no glob matches the empty string), but a future glob
addition (for example a top-level wildcard) would otherwise spuriously
flip 'source=true'.

preview.yml — fix the wording in the diff-failure comment. The code
uses command substitution ($(...) ), not process substitution
(<(...) ); the actual reason 'set -e' does not propagate is that the
'if !' wrapper context disables propagation. Restate accordingly.

preview.yml — pre-resolve template variables for the source-SHA
heredoc into env vars (DISPATCH_SHA, WORKFLOW_RUN_SHA). The previous
form inlined '${{ github.sha }}' directly into a shell run block;
the env-var form is consistent with the rest of the workflow's
substitution style and makes a future copy-paste of a user-controlled
template field harder to do unsafely.

ci.yml, construct.yml — trim the 'workflow_dispatch is an explicit
operator action' rationale comments. The step name 'Force rust=true on
workflow_dispatch' (and its construct.yml twin) already carries the
WHAT and the immediate WHY; the comment was a near-narration of the
step name.

ci.yml — drop the two 'Toolchain channel comes from
rust-toolchain.toml.' WHAT comments. The action's behavior is
documented upstream and not project-specific.

renovate.json — drop the redundant 'packageNameTemplate' on the MISE
manager. Renovate falls back to 'depName' when 'packageName' is
unset, so the second line was a no-op.

docs.yml — add a one-line comment on the 'changes' job explaining
that schedule runs only 'check-deployed' by design, so a future
maintainer adding 'needs:' on another job does not silently re-include
schedule via the dependency chain.

Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com>
Co-authored-by: Claude <noreply@anthropic.com>

…t deployed-docs composite action

Address the originally-deferred items from the path-aware gating PR's
follow-up list.

Aggregator jobs (ci.yml, construct.yml, docs.yml) — add a per-workflow
'\*-required' job that uses 'if: always()' + a 'jq' check over
'toJSON(needs)' to fail when any upstream job failed or was cancelled.
Skipped jobs are treated as success (the entire point of path-aware
gating). This gives branch protection a single stable check name to
list per workflow, so adding or removing gated jobs in the future does
not require updating the protection rule. Branch protection is not
configured today; the aggregators are forward-looking infrastructure
that costs nothing to add now and avoids a chicken-and-egg problem
later.

construct.yml — collapse 'build-amd64' and 'build-arm64' into a single
matrix-strategy 'build' job. The previous form duplicated 58 lines of
near-identical steps; the only differences (runner label, platform
string, cache scope, registry buildcache ref, artifact name, digest
path) are now matrix variables. 'fail-fast: false' preserves the prior
behavior where one architecture failing does not cancel the other.

construct.yml — drop 'setup-buildx-action' and 'Bootstrap buildx' from
the 'publish-manifest' job. That job only runs 'docker buildx
imagetools create' and 'inspect', both of which are registry-side
operations that use the buildx CLI plugin (bundled with Docker on
ubuntu-24.04) but require no local builder container. The previous
form spun up an unused docker-container builder and bootstrapped it
purely to throw it away. The build jobs above keep the buildx setup
because actual layer builds do require the docker-container driver.

construct.yml — pull the builder name and digest directory out into
workflow-level env vars (BUILDX_BUILDER, DIGEST_DIR) so the literal
strings 'jackin-construct' and '/tmp/jackin-construct-digests' are no
longer repeated across multiple steps.

docs.yml — extract the 'restore lychee cache → prepare → collect URLs
from sitemap → check links' sequence shared by 'deploy' and
'check-deployed' into a composite action at
'.github/actions/check-deployed-docs/action.yml'. The two callers had
~30 lines of identical steps; the composite action collapses both call
sites to one 'uses: ./.github/actions/check-deployed-docs' invocation
each, parameterized on lychee version, sitemap URL, edit/blob URL bases,
and the GitHub token. The two callers can no longer drift on remap
rules or cache-key shape.

Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com>
Co-authored-by: Claude <noreply@anthropic.com>

…ts mise

Renovate's 'deb' and 'github-releases' datasources both fail silently
on a missing or renamed upstream — they return 'no updates available'
rather than raising — so a URL that 404s or a renamed package would
silently re-introduce the same version drift the customManagers added
in this PR were meant to prevent. 'renovate-config-validator --strict'
only validates JSON shape; it does not fetch from the configured URLs.

Add a small validation workflow that runs on every PR and every push
to main:

  1. Strict schema validation of renovate.json.
  2. Curl the deb Packages index for the MISE manager's
     registryUrlTemplate at suite=stable, components=main,
     binaryArch=amd64. Fail loud on a transport error or a missing
     'Package: mise' entry in the index.

Smoke-tested against the live URL — the index currently lists
'Package: mise' as expected.

Sibling managers (TIRITH on github-releases, SHELLFIRM on crate) could
be checked the same way; left as a follow-up because their drift mode
is less subtle (a renamed crate or repo would surface as an obvious
404 in the upstream UI, while a renamed apt package would not).

Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com>
Co-authored-by: Claude <noreply@anthropic.com>

… repo config

The previous invocation 'renovate-config-validator --strict renovate.json'
treats the supplied file as a self-hosted global configuration. Under
that mode the validator rejects 'managerFilePatterns' on customManagers
because that field is only valid inside a repo configuration. The result
was a freshly-broken CI check on this PR (the validator passed locally
because the local default differs from the CI default in newer Renovate
versions).

Add --no-global so the validator interprets renovate.json the same way
the bot itself does when it scans the repo. Verified locally:

  $ npx renovate-config-validator --strict --no-global renovate.json
  INFO: Validating renovate.json as repo config
  INFO: Config validated successfully

Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com>
Co-authored-by: Claude <noreply@anthropic.com>

Switch from 'npx renovate-config-validator' to the SHA-pinned
'rinchsan/renovate-config-validator' action. The npx-based form was
picking up an older renovate from the public npm registry that has two
problems against this repo's renovate.json:

  - It rejects 'managerFilePatterns' on customManagers when treating
    the file as a self-hosted global config.
  - It does not yet expose the '--no-global' flag that would tell it
    to validate as a repo config.

Local validation under '@latest' worked because npm resolves a newer
version on developer machines than CI was getting. Pinning a
maintained validator action eliminates that drift entirely.

Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com>
Co-authored-by: Claude <noreply@anthropic.com>

…cation

The 'renovate-config-validator' behavior on 'customManagers.managerFilePatterns'
varies across renovate npm versions in a way that produced a false
negative in this PR's CI run: the validator under the GitHub-hosted
runner rejected the field as 'disallowed' even though identical input
on a developer machine and identical input passed to the live
Renovate bot validates cleanly. Pinning the validator action did not
help because the action delegates to the same npx-resolved renovate.

Drop the schema check rather than fight a moving target. The live
Renovate bot validates renovate.json on every dependency-dashboard
cycle, so a real schema break would still surface — just with one
day of delay instead of in CI.

Keep the high-leverage check: curl the deb 'Packages' index for the
MISE manager's registryUrlTemplate and assert 'Package: mise' is
present. That is the failure mode this workflow exists to catch
(silent drift from a renamed upstream); the schema check was
incidental.

Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com>
Co-authored-by: Claude <noreply@anthropic.com>

…rmissions, comment cleanup

Address findings from the third-pass /simplify review.

construct.yml — add the workflow-level 'permissions: contents: read'
block that every other workflow in this PR already declares. The
previous form left the 'changes' job and the 'construct-required'
aggregator running with whatever the repo default token scope is,
inconsistent with ci.yml / docs.yml / preview.yml /
renovate-validate.yml.

construct.yml — hoist the 5x-repeated 'github.event_name == push ||
(github.event_name == workflow_dispatch && github.ref ==
refs/heads/main)' boolean (and its two inverse occurrences) into a
single 'is_publish' output on the 'changes' job. Downstream steps
gate on 'needs.changes.outputs.is_publish == "true"' (or
'!= "true"') instead of restating the same expression seven times.

construct.yml — promote the registry image coordinate
'projectjackin/construct' into a workflow-level env var
'REGISTRY_IMAGE'. The buildcache cache-from / cache-to refs now
interpolate that env var instead of hardcoding the literal twice.

Add '.github/actions/aggregate-needs/action.yml' as a composite
action and call it from each workflow's '*-required' aggregator job
('ci-required' in ci.yml, 'construct-required' in construct.yml,
'docs-required' in docs.yml). The previous form duplicated the same
'set -euo pipefail' + 'jq -e to_entries | map(.value.result) |
any(. == failure or . == cancelled)' shell body across three call
sites with only the failure-message string differing. The composite
action takes 'needs-json' (caller passes 'toJSON(needs)' since
composite actions cannot read the parent job's needs context) and
'workflow-label' inputs.

Standardize multi-line 'if:' clauses on YAML's '>-' folded-chomp
style. construct.yml's 'publish-manifest' and docs.yml's
'check-deployed' previously used '|' literal block; the rest of the
PR (ci.yml's 'build-validator', preview.yml's 'source-changed') used
'>-'. GitHub's expression parser tolerates either, but '>-' is the
idiomatic GHA choice for inline boolean expressions and matches the
majority of the PR.

renovate-validate.yml — drop the 'actions/checkout' step. The single
remaining assertion runs 'curl' against an external URL and reads no
repo files, so the checkout was dead weight.

ci.yml — drop the comment claiming the dispatch and filter steps
are mutually exclusive on event_name. The two steps' 'if:' guards
make the mutual exclusivity literally visible two lines below; the
comment was narration of the design rather than a hidden invariant.

construct.yml — drop the redundant 'BUILDX_BUILDER' WHAT comment
(the env var name carries the meaning); keep the DIGEST_DIR comment
because that one documents a write/read contract between two jobs.

docs.yml — replace the 'src/runtime/launch.rs' example in the
'repo-link-check' rationale with 'a referenced file', matching the
agent-only AGENTS.md guidance against memorializing specific paths
in code comments.

Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com>
Co-authored-by: Claude <noreply@anthropic.com>

The previous description embedded a literal '${{ toJSON(needs) }}'
example. GitHub Actions parses input descriptions as expression
strings, and 'needs' is not in the composite-action scope, so the
manifest failed to load with 'Unrecognized named-value: needs'.

Replace the example with prose that explains the same contract
without using GHA expression syntax inside the description.

Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com>
Co-authored-by: Claude <noreply@anthropic.com>

…culative env rationale

Apply two final-pass comment-audit findings.

publish-manifest comment — strip the two narration sentences ('the
previous setup-buildx-action / construct-init-buildx pair has been
dropped here', 'Build jobs above keep them because actual layer
builds…'). Per AGENTS.md, the git history is the record of what
changed; the comment should describe only the current shape. Keep
the WHY (imagetools is registry-side, no local builder needed) plus
an affirmative 'no setup here' so the absence reads as intentional.

REGISTRY_IMAGE comment — drop the 'future tag arithmetic'
speculation; nothing in this workflow does tag arithmetic and the
hypothetical phrasing ages poorly. State the actual current purpose
(keeping the two buildcache refs in sync).

Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com>
Co-authored-by: Claude <noreply@anthropic.com>

…ling slash

Two forward-looking review findings.

check-deployed-docs/action.yml — add a 'Validate URL inputs' step
that asserts 'sitemap-url', 'edit-url', and 'blob-url' match a plain
http(s) URL shape with no shell-special characters, before any of
them flow into the lycheeverse/lychee-action 'args:' block. lychee
itself treats them as URL prefixes / regex remap rules, but a future
caller passing an attacker-controlled value containing quotes or
backslashes could break the embedded '--remap "<url>/(.*) …"'
quoting. Today's two callers pass workflow-env constants and
actions/deploy-pages output, so the check is forward-looking
hardening — fail loud if a future caller deviates rather than waiting
for a malformed lychee invocation. The values still pass through
'env:' inside the validate step (not direct '${{ }}' substitution
into bash) so the validator itself is injection-safe.

docs.yml deploy job — add a 'Resolve sitemap URL' step that
explicitly strips any trailing slash from
'${{ steps.deployment.outputs.page_url }}' before appending
'sitemap-0.xml'. The current actions/deploy-pages version emits
page_url with a trailing slash, so the previous concatenation
'${{ … }}sitemap-0.xml' produced a well-formed URL. If a future
deploy-pages version drops that contract, the previous form would
emit 'https://…sitemap-0.xml' (host and path glued together) and
lychee would fail loudly — but the brittle implicit dependency is
worth eliminating now that the cost is two extra lines.

Both changes are no-ops on today's inputs.

Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com>
Co-authored-by: Claude <noreply@anthropic.com>