knowledge began as a simple JSON note store. Current project mode uses a
app workspace and a versioned SQLite catalog:
.hasna/knowledge/
db.json
knowledge.db
artifacts/
indexes/
logs/
runs/
schemas/
wiki/
The JSON store remains available for compatibility with note commands such as
add, list, get, update, delete, and export. The SQLite catalog is
used for source refs, source revisions, chunks, citations, embeddings, wiki
pages, generated artifacts, runs, audit events, and reindex jobs.
Global legacy notes are migrated on first use:
~/.open-knowledge/db.json
to:
~/.hasna/knowledge/db.json
This happens only when the new app JSON store does not already exist. The legacy file is not deleted.
Project mode writes directly to:
<project>/.hasna/knowledge/db.json
when compatibility note commands are used with --scope project.
SQLite knowledge records are not inferred from old JSON notes automatically. Use explicit commands so provenance, permissions, citations, and redaction are recorded correctly.
Initialize the project catalog:
knowledge db init --scope project --json
knowledge wiki init --scope project --jsonImport open-files manifests:
knowledge ingest manifest ./open-files-manifest.jsonl --scope project --jsonImport one allowed source ref:
knowledge ingest source file:///absolute/path/to/handbook.md \
--purpose knowledge_index \
--scope project \
--jsonResolve indexed source evidence:
knowledge source resolve open-files://file/file_123/revision/rev_456 \
--purpose knowledge_answer \
--scope project \
--json- Keep the legacy JSON note store as an exportable compatibility layer.
- Run
knowledge paths --scope project --jsonand confirm the project workspace is.hasna/knowledge. - Initialize
knowledge.dbwithknowledge db init --scope project. - Ingest source manifests from
open-filesrather than copying raw files intoknowledge. - Run
knowledge search --scope project --jsonto verify source chunks. - Run
knowledge wiki compilefor durable cited pages. - Run
knowledge wiki lint --scope project --jsonbefore treating pages as company knowledge. - Use
knowledge export --format jsonlif legacy notes need to be archived or transformed outside the app.
Use --json during migration. Commands return stable objects with ok: true
when successful and command-specific fields such as:
paths: workspace paths and config.db stats: schema version and table counts.ingest manifest: sources, revisions, chunks, redactions, and skipped rows.source resolve: read-only source metadata, chunks, citations, and evidence.search --context: excerpts, citations, graph evidence, and warnings.ask|build: run id, answer, context, citations, proposed wiki updates, write policy, usage, and warnings.wiki compile: page id, artifact URI, citations written, index updates, and log shard key.
- Prefer
open-files://refs for durable company sources. - Keep raw source bytes in
open-files; do not import them as generated wiki artifacts. - Enable S3 reads only for allowed buckets:
HASNA_KNOWLEDGE_ALLOW_S3_READS=1 \
HASNA_KNOWLEDGE_ALLOWED_S3_BUCKETS=my-bucket \
knowledge ingest manifest s3://my-bucket/path/manifest.jsonl \
--scope project \
--json- Enable web search only when current external context is required:
HASNA_KNOWLEDGE_WEB_SEARCH=1 \
knowledge web search "current policy source" --provider openai --json- Use
--approve-writeonly when a generated wiki artifact should be durable.
Hosted mode should not change local migration semantics. It only records a remote API boundary:
knowledge setup --mode hosted --api-url https://knowledge.md --scope project --json
knowledge remote contracts --scope project --jsonA SaaS wrapper can later sync generated artifacts, run jobs, enforce tenant ACLs, and store artifacts in S3, but the local package remains usable without a hosted account.