I went through the $HONEY docs (docs.hivemapper.com) and the Bee Maps API docs. I crawled all 46 pages in the docs sitemap and checked every link: 34 internal links return 404, spread over 13 pages. Most are relative-link mistakes. For example, the "What is HONEY" link on the Global Map Progress page resolves one folder too deep, so it 404s. Two links still point at old GitBook "broken pages" URLs, and the docs' links to the old Explorer and Network Coverage pages on hivemapper.com are 404 too. The live map now sits on the Coverage page.

The coverage numbers disagree. The Coverage page shows 38% and 790M km, but its own meta description says 34% and "500M+". The API reference says 36%, and the Data API page says 37%.

The curl example on the Data API page uses an "imagery latest poly" route that answers 404 Cannot POST, while the API reference uses a "latest poly" route that answers 403 with a dummy key, so only the reference route exists.

Suggestion: add a link checker to the docs build. Question: which coverage figure should integrators quote?

I tried to pull LST data from Sanctum ($SANC) the way a new developer would, starting at learn.sanctum.so.

The Sanctum API page lists 10 endpoints on sanctum-api.ironforge.network. Its .md version, the one llms.txt points to, contains only /lsts and /lsts/[mint or symbol]. Every endpoint requires apiKey, and I couldn't find anywhere that says how to get one. With no key I get 401 "Missing API key.", and with a wrong one I get 400 "Invalid API key."

The "A few things you should know about" page links the trading API at api.sanctum.so, which returns HTTP 530 (Cloudflare error 1016). The stats API at extra-api.sanctum.so works without a key. But /v1/apy/latest returns 0.0 for INF, jupSOL and even the spec's own example list, with an empty errs object. Meanwhile /v1/apy/inception gives INF 0.0692 and jupSOL 0.0688.

There are two small link bugs as well. The vanity-keypair link ends in an escaped ")" and returns 404, and the Metaplex storage-providers link is a 404 too.

Suggestion: return an error in errs rather than a silent 0.0. Question: has api.sanctum.so been retired in favour of the ironforge host?

I followed the $NOS CLI quick start as far as I could without funding a wallet. `npm install @nosana/cli` on Node 20 gave me v1.0.133, though the docs' sample output still shows 0.3.0. `nosana address` created ~/.nosana/nosana_key.json. The docs say .nosana_key.json, and the file came out with 644 permissions.

The hello_world.json from the docs validates fine. Then I broke it on purpose. Renaming "image" to "imgae" gives "Invalid Job Definition" with expected '(__type.o9 | __type.o21)', which never names the bad key. Duplicate op ids are caught, which is nice. But `nosana job validate` exits 0 on invalid files, so a CI step can't use it as a gate. (@nosana/kit's validateJobDefinition reports the clearer '(ContainerRun | ContainerCreateVolume)'.)

`nosana market get 7AtiX…` (the 3060 market from the quick start) crashes when stdout is piped, with "TypeError: process.stdout.moveCursor is not a function". It works in a real terminal and shows 0.000023 NOS/s.

Suggestion: exit non-zero on invalid definitions. Question: is the 3060 market still the recommended one for a first job? The hello-world page uses the 4090 market instead.