Skip to content

docs(site): fix strict-build failure — root-relative links (Pages deploy red since 07-08) #290

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
pilotspacex-byte merged 1 commit into from
Jul 12, 2026
Merged

docs(site): fix strict-build failure — root-relative links (Pages deploy red since 07-08) #290

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,16 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0

## [Unreleased]

### Fixed — docs site strict build red since 2026-07-08 (root-relative links)

`docs/guides/tuning.md` (PR #245) and `docs/PRODUCTION-CONTRACT.md` (PR #263)
linked repo-root files (`BENCHMARK.md`, `RELEASES.md`,
`.github/workflows/release.yml`) via relative paths that escape the MkDocs
`docs/` tree — `mkdocs build --strict` aborts on the 5 resulting warnings, so
the GitHub Pages deploy had failed on every main push since 2026-07-08.
Converted the 5 links to absolute GitHub blob URLs; strict build verified
clean locally. Docs-only.

### Changed — WAL v3 `wal_append` channel now preserves the caller's REAL record type end-to-end (K1a, storage-kernel M1 stage 1)

`ShardDatabases::wal_append` / `try_wal_append_required` and
Expand Down
6 changes: 3 additions & 3 deletions docs/PRODUCTION-CONTRACT.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ description: "Moon's v1.0 promises: SLOs, durability modes, supported platforms,
what the `v1.0` release gate checks.
**Last updated:** 2026-07-10
**Milestone:** v0.6.1 Hygiene & reliability hotfix
**Current release:** v0.6.0 (2026-07-08, PR #249) — see [`RELEASES.md`](../RELEASES.md)
**Current release:** v0.6.0 (2026-07-08, PR #249) — see [`RELEASES.md`](https://github.com/pilotspace/moon/blob/main/RELEASES.md)
**Roadmap:** [`docs/roadmap/ROADMAP.md`](roadmap/ROADMAP.md) §1 (proven strengths / reality check) is the
authoritative source this ledger was verified against.

Expand All @@ -21,7 +21,7 @@ shipped). **No aspirational ticks** — a row is only ✅ if the linked evidence
exist and do what the row claims, as of this refresh.

`scripts/check-production-contract.sh` greps this file and is wired into
[`.github/workflows/release.yml`](../.github/workflows/release.yml):
[`.github/workflows/release.yml`](https://github.com/pilotspace/moon/blob/main/.github/workflows/release.yml):

- On any `v0.x` tag it **reports** unticked GA-blocking rows but does not fail the build — Moon is
pre-GA and the whole point of this ledger is to track the gap honestly.
Expand All @@ -46,7 +46,7 @@ in `.github/workflows/ci.yml`); production **benchmark numbers** still MUST come

## Performance

Numbers are tracked in [`BENCHMARK.md`](../BENCHMARK.md) (KV pipelined/p=1, vector iso-recall vs
Numbers are tracked in [`BENCHMARK.md`](https://github.com/pilotspace/moon/blob/main/BENCHMARK.md) (KV pipelined/p=1, vector iso-recall vs
Qdrant/RediSearch, graph vs FalkorDB), refreshed per release rather than pinned as static SLOs in
this document — no automated 24h HDR rig or Criterion CI regression gate exists yet (`PERF-01`/`PERF-02`
below are unticked). Headline, evidence-cited numbers as of v0.6.0:
Expand Down
4 changes: 2 additions & 2 deletions docs/guides/tuning.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -128,7 +128,7 @@ Moon's AOF write path is engineered so that durability is cheap at pipeline dept
device-bound (not server-bound) when you demand fsync-per-write. The mechanics below are
**automatic — there are no knobs to turn** — but knowing them tells you which policy fits
your workload. Measured on GCE `c3-standard-8` (pd-ssd), `--shards 2`, vs Redis 7.0.15;
full matrix in [`BENCHMARK.md` §7.3](../../BENCHMARK.md).
full matrix in [`BENCHMARK.md` §7.3](https://github.com/pilotspace/moon/blob/main/BENCHMARK.md).

- **`everysec` (default): a win, not just free.** At pipeline depth SET runs **~1.32×
Redis** (the writer coalesces each batch into one `write_all` and polls its queue
Expand Down Expand Up @@ -164,7 +164,7 @@ faster than a subscriber's socket drains, the whole burst is delivered in one `w
instead of one syscall per message. In practice this means a fast publisher fanning out to
many subscribers is no longer syscall-bound: measured fan-out delivery reached **5.09M
msg/s (≈1.04× Redis) with zero drops**, versus near-total message loss on a per-message
write path (see [`BENCHMARK.md` §7.3](../../BENCHMARK.md)). There are no knobs to turn.
write path (see [`BENCHMARK.md` §7.3](https://github.com/pilotspace/moon/blob/main/BENCHMARK.md)). There are no knobs to turn.

The one thing to know: each subscriber has a bounded in-flight queue (256 messages). A
subscriber that stays slower than the publish rate will still have messages **dropped** —
Expand Down
Loading