Helix knew how to look things up in your project. It did not know what your project was — the decisions, the constraints, the vocabulary a new teammate picks up in their first fortnight. Project context is that missing layer.
A brief, and the documents behind it
Every project now builds a brief: a short, current description of what the project is and where it stands. Underneath it sits a set of context documents — one per topic, each with a title, a description, and a summary — built from the project’s own material: wiki pages, requirements, meetings, and delivery history.
Both are editable. Correct the brief and it stays corrected. Lock a document and refreshes leave it alone, so a hard-won description of your billing rules isn’t quietly rewritten the next time context rebuilds.
Context refreshes on a schedule and can be rebuilt on demand from the project settings. Reads are passive — opening or querying context never triggers ingestion — so a rebuild only happens when you ask for one.
Search that understands the question
Context documents are embedded and searched by meaning, not just by keyword. Asking about “who signs off on a release” finds the approval policy document even when it never uses those words. Where vector indexing isn’t available the search falls back to keyword matching rather than returning nothing.
Helix reads it before it answers
Project context is exposed to Helix as an ordinary entity it can query, create, and update — the same shape as stories, bugs, and wiki pages, rather than a separate set of bespoke tools. Helix must search context before reading it, so answers come from the documents that actually match the question instead of whatever was loaded first.
Built to survive large projects
Initial ingestion collects the project’s full history rather than the most recent slice, then works through it in pages with bounded concurrency and rate limiting. Source material is processed in chronological order, so later decisions supersede earlier ones instead of racing them.
Documents carry stable IDs and merge on update, and a document is only updated when its title matches exactly — which stopped the duplicate near-identical documents that earlier builds accumulated. Wiki hierarchy is preserved in the source text, so a nested page keeps the meaning it gets from its parents.
This replaces the earlier project facts pipeline, which has been removed.
Also in this release
- Priority and severity have been removed from QA test entities. If you read or write test cases through the API or an MCP client, drop those fields — requests that still send them will no longer have any effect. ⚠️
- The unit test report handles apps with no test data instead of failing the report for the whole run.