Skip to content

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

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
andrei-hasna merged 1 commit into from
Aug 1, 2026
Merged

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

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
20 changes: 10 additions & 10 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -515,14 +515,13 @@ every path and the loaded config.
```bash
knowledge mode [--json]
```
Report which backend this process would use — `local` (the on-box store) or
`cloud` (the HTTP `/v1` API) — and which environment variable selected it.
Report which backend this process would use — `sqlite` (the on-box store) or
`postgres` (the HTTP `/v1` API) — and which environment variable selected it.

Selection is **explicit only**. Set `HASNA_KNOWLEDGE_STORAGE_MODE=local|cloud`
Selection is **explicit only**. Set `HASNA_KNOWLEDGE_STORAGE_MODE=sqlite|postgres`
(aliases `HASNA_KNOWLEDGE_MODE`, `KNOWLEDGE_STORAGE_MODE`, `KNOWLEDGE_MODE`, in
that precedence order; `self_hosted` is accepted as a deprecated spelling of
`cloud`). Setting `HASNA_KNOWLEDGE_API_URL` / `HASNA_KNOWLEDGE_API_KEY` alone
does **not** switch backends — those are pointers saying where the cloud is and
that precedence order). Setting `HASNA_KNOWLEDGE_API_URL` / `HASNA_KNOWLEDGE_API_KEY` alone
does **not** switch backends — those are pointers saying where the API is and
how to authenticate, and `mode` reports them as present-but-ignored so a machine
that has them exported in its shell is not silently reading a different store
than a machine that does not.
Expand Down Expand Up @@ -731,8 +730,9 @@ the remote repo root or remote `.hasna/knowledge` path.
`knowledge sync` owns knowledge semantics and conflict visibility for
peer/machine catalog transfer. It is distinct from `db storage status`, which is
a read-only local catalog inspector. (The legacy `db storage sync`/`push`/`pull`
Postgres-DSN commands were removed; cross-machine sharing uses cloud mode —
`HASNA_KNOWLEDGE_STORAGE_MODE=cloud` plus `HASNA_KNOWLEDGE_API_URL` +
Postgres-DSN commands were removed; cross-machine sharing uses the postgres
backend through the HTTP API — `HASNA_KNOWLEDGE_STORAGE_MODE=postgres` plus
`HASNA_KNOWLEDGE_API_URL` +
`HASNA_KNOWLEDGE_API_KEY` — instead. The mode var is required: the two pointer
vars on their own do not switch backends. See [`mode`](#mode).)

Expand Down Expand Up @@ -768,8 +768,8 @@ Initialize or inspect the versioned SQLite catalog at
durable table list, and local sync history. It is read-only. The legacy
`push`/`pull`/`sync` Postgres commands and the client `HASNA_KNOWLEDGE_DATABASE_URL`
DSN were removed — a raw database DSN is never distributed to clients. To share
knowledge across machines, use cloud mode instead: set
`HASNA_KNOWLEDGE_STORAGE_MODE=cloud` **and** `HASNA_KNOWLEDGE_API_URL` +
knowledge across machines, use the postgres HTTP API backend instead: set
`HASNA_KNOWLEDGE_STORAGE_MODE=postgres` **and** `HASNA_KNOWLEDGE_API_URL` +
`HASNA_KNOWLEDGE_API_KEY` so every read/write routes through the HTTP API. The
mode var is **not** optional and the pointer vars are **not** a substitute for
it: presence of a URL and a key never switches backends on its own. Run
Expand Down
Loading
Loading