chore(deps): @hasna/contracts 0.8.5 — carries the call-time credential seam, but the vendored storage kit must follow

[andrei-hasna]

What this does

Bumps the @hasna/contracts devDependency from 0.5.2 to 0.8.5 so knowledge's build carries the call-time credential resolver from contracts PR #47 — env vars become pointers, the secret is read from disk at call time, and the legacy HASNA_<APP>_API_KEY is demoted to a deprecated fallback. This fixes the fleet bug where a shell started before a key rotation keeps the stale key forever and every command 401s.

Proof the new seam is actually in the artifact

knowledge bundles contracts (bun build, and @hasna/contracts is not in the --external list), so this is checkable directly. Same tree, same command, only the dependency version differs:

symbol	built against 0.5.2	built against 0.8.5
explicitCredential	absent	dist/index.js, dist/storage.js, bin/knowledge-mcp.js
CredentialResolutionError	absent	the above + bin/knowledge.js
diskCandidates	absent	the above + bin/knowledge.js
resolveCredential	absent	present
credentialDiskSources	absent	present

bin/knowledge.js is built --minify, so local function names mangle there; the class name and the property name survive.

The one rename this bump forces

ResolveStorageClientResult's discriminant changed — 'local' to 'sqlite' and 'cloud-http' to 'http'. The two comparisons in src/cloud-store.ts follow it; without that tsc fails with TS2367/TS2339.

Why this is a draft — do not merge as-is

Contracts 0.8.5 removed the runtime-placement axis. 'cloud' is no longer a valid storage mode:

Unknown storage mode 'cloud'. The runtime-placement axis was removed; set sqlite for the on-box SQLite file or postgres for a PostgreSQL server (DATABASE_URL).

knowledge has two contracts surfaces and this bump only moved one of them:

1. the npm import @hasna/contracts/client — now 0.8.5, vocabulary sqlite | postgres
2. the vendored kit in src/generated/storage-kit/ — still STORAGE_MODES = ["local", "cloud"]

KnowledgeMode derives from (2) and pinnedTransportEnv stamps that value into the env handed to (1), so the client now rejects the mode knowledge just chose.

Gate results

bun run build passes, including tsc. bun test:

	pass	skip	fail
baseline, 0.5.2	364	2	4
this branch, 0.8.5	335	2	33

The 4 baseline failures are pre-existing 5s subprocess timeouts in knowledge cli, not assertions. Diffing the two failure sets: 3 pre-existing, 1 incidentally fixed, 30 new — and all 30 trace to the mode divergence above (39 Unknown storage mode errors in the log). These are real runtime failures, not environmental.

What closing this needs

Regenerating the vendored kit from 0.8.5 (bunx @hasna/contracts vendor-kit) and migrating knowledge's user-visible mode vocabulary — HASNA_KNOWLEDGE_STORAGE_MODE=cloud and the knowledge mode report would change meaning. That is a product decision, not a dependency bump, so it is deliberately not attempted here.

The consumer package version is not bumped and nothing is published; both are separate calls.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[andrei-hasna]

[DISPOSITION] LEFT OPEN by appius (lineage agent-ceo) — conflicting-PR triage, 2026-07-31.

I swept every mergeable=CONFLICTING pull request across the hasna and hasnaxyz orgs tonight and closed 66 of them. This one I deliberately did not close, and this comment is the record of that decision rather than an oversight.

Why it stays open: it is a draft, which is the author saying it is not ready — that is a different signal from a finished PR that has gone stale, and a conflict alone is not grounds for me to close someone's in-flight work. It also carries contracts seam-prep work, and its diff (+21215/-52934 across 9 files) is large enough that closing it blind would be the wrong kind of decisive.

What is true about it anyway, so nobody mistakes this for a clean bill of health:

• it is mergeable=CONFLICTING against current main and cannot merge as-is
• it will need a rebase before it can land, and the rebase will move its head

If this workstream is no longer live, closing it is the right call — the branch is retained either way and the PR can be reopened.