Publish streamcore-cli — RAG ingestion is documented against a 404

[jason-shen]

Problem

docs/agent-runtime.md documents document ingestion against a binary nobody can get:

streamcore-cli is not public yet. github.com/streamcoreai/streamcore-cli currently returns 404, so the clone below will fail. The flags and behaviour documented here are accurate for when it ships — until then, ask in Discord if you need document ingestion.

The docs go on to give the full command surface — streamcore-cli ingest over .txt, .md, .csv, .pdf, .docx, .xlsx, with --config, --provider, --chunk-size, --chunk-overlap — and a flag table.

The consequence is that RAG is half a feature. The server does query-time retrieval and is documented as such; the only supported way to populate the vector store is a 404. Anyone who wants RAG today either writes their own embedding and insert path against whatever schema internal/rag expects, or asks in Discord. Both are worse than the tool that already exists.

Proposed change

Publish it. The binary exists and its structure is already settled — a Go module with internal/parser, internal/chunker, internal/embed, internal/store, and a setup command that writes a config matching the server's config.toml shape, so credentials are configured once.

What publishing actually requires:

• A public streamcoreai/streamcore-cli repo with LICENSE, README (plus the zh-CN mirror, per convention), and a CI workflow matching this repo's: gofmt, build, vet, go test -race.
• A real schema contract with the server. The CLI writes rows that internal/rag/pgvector.go and internal/rag/supabase.go read. Today that agreement is implicit in two codebases. It needs to be written down — the exact table DDL, the embedding dimension, and which embedding_model values are compatible with which stored vectors. Insertions with a mismatched model produce a store that retrieves nonsense and gives no error, which is the worst way for this to fail.
• A migration or setup path for the pgvector table, so streamcore-cli setup leaves a working store rather than assuming one exists.
• Released binaries. Same argument as for the server: a static Go binary that requires a toolchain to obtain is needlessly hard to adopt. goreleaser, tagged releases, macOS and Linux on both architectures.
• Docs updated to remove the 404 warning, in docs/agent-runtime.md and its zh-CN mirror, plus a worked end-to-end example: ingest a PDF, ask the agent something only that PDF answers.

Worth deciding at the same time, because it is easier to decide before release than after: whether ingestion belongs in a separate binary at all, or whether it should be a subcommand of the server so there is one artifact and one config. A separate binary keeps parsing dependencies (PDF, docx, xlsx) out of the server image, which is a good reason to keep it as it is — but it should be a decision, and it should be written down.

Acceptance criteria

• streamcoreai/streamcore-cli is public, with LICENSE, README, README.zh-CN.md, and CI.
• git clone && go build produces a working binary, and tagged releases carry prebuilt ones.
• Table DDL and embedding-dimension contract documented in both repos.
• Mismatched embedding model or dimension fails loudly at ingest time rather than silently at query time.
• streamcore-cli setup produces a store the server can query with no manual SQL.
• The 404 warning is removed from docs/agent-runtime.md and the zh-CN mirror.
• Worked example: ingest a document, ask a question only it can answer, get the right answer.

Pointers

• docs/agent-runtime.md:145 — "Ingesting documents", the section this unblocks
• internal/rag/pgvector.go, internal/rag/supabase.go — the read side of the schema contract
• internal/rag/embedding.go — embedding model handling on the server side
• config.toml.example — [rag], [pgvector], [supabase] sections the CLI reads
• Related: Versioned releases: no tags, no changelog, no version in the binary #53 (versioned releases — same release tooling applies)