Project context
Context is what WeHarness knows about a project’s code. It is everything later steps read, such as the plan, the guidance and the checks. Context comes from sources. Each time a source is updated, WeHarness records an immutable snapshot of it.
Ways to add context
Section titled “Ways to add context”| Source | How | Status |
|---|---|---|
| A folder | Choose a folder in a session’s Context tab. Files are read in your browser. | Available |
| A zip file | Upload a zip in the Context tab. The archive is unpacked in your browser, not on our servers. | Available |
| No files yet | Start without files for a new project. The project’s intent is its starting context. | Available |
| A GitHub repository | Connect the WeHarness GitHub App and pick a repository and branch. See GitHub. | Available |
| Your coding tool’s working copy | Ask your coding tool to use WeHarness on the folder it has open. It sends the folder’s text files over MCP. See Your local project. | Available |
What is left out, and why
Section titled “What is left out, and why”WeHarness applies a versioned intake policy (intake-policy-1) before it asks for any file content. Your browser sends only paths, sizes and fingerprints first. WeHarness then asks only for the files the policy accepts.
| Left out | Examples | Why |
|---|---|---|
| Secrets | .env and every .env.* file, private keys, *.pem, credential files, .ssh/, Terraform state |
Never read, never stored, never sent to any provider |
| Credentials inside files | Private key blocks and well-known token formats found in otherwise ordinary files | The file is not stored |
| Dependencies | node_modules, vendor, virtual environments |
Not your project’s code |
| Build output and caches | dist, build, target, .next, __pycache__ |
Generated |
| Version control data | .git, .hg, .svn |
Not needed; history is not read |
| Binary files and documents | Images, archives, executables, PDFs, Office files | A repository is read as text. Documents and images you attach to a session are read separately (see below) |
| Minified files | *.min.js, source maps |
Generated |
| Symbolic links | Any link | Recorded, never followed |
| Submodules and Git LFS files | Submodule pointers, LFS pointer files | Recorded as missing; not fetched |
| Unsafe paths | .. segments, absolute paths, control characters, hidden text-direction characters |
Rejected |
Text files can use any encoding: UTF-8, UTF-16 or UTF-32 with a byte-order mark, or a legacy encoding such as Windows-1254, Shift-JIS, GB18030, Big5 or EUC-KR. Legacy encodings are detected and decoded, and the index lists the files it decoded. When the detected encoding is uncertain, for example in a very short file, the file is still indexed and appears under coverage gaps as “Text encoding guessed”, because its text may be garbled.
Files in the repository, such as a README or .gitignore, cannot change these rules. Text that asks an AI to include secrets or approve actions is treated as ordinary file content.
Limits
Section titled “Limits”| Limit | |
|---|---|
| Files per snapshot | 20,000 |
| Total size | 250 MB |
| One file | 1 MB (dependency manifests and lock files: 10 MB) |
A selection over these limits is refused before anything is uploaded. Choose a smaller folder or a single package.
The preflight
Section titled “The preflight”Before anything is sent, you see a preflight: how many files will be included and how many are left out, grouped by reason. Nothing is uploaded until you confirm.
Snapshots
Section titled “Snapshots”When the upload is complete, WeHarness commits the snapshot:
- The full list of entries, including what was left out and why, becomes immutable. It gets a fingerprint (a manifest digest). Two snapshots with the same content have the same digest.
- The new snapshot replaces the previous one from the same source. Earlier snapshots stay listed.
- Indexing starts automatically and appears as a run with a live timeline. See Search.
A snapshot can also record uncommitted changes: modified, added, deleted and untracked files relative to a base commit. A folder uploaded from a browser cannot see Git status, so its files are marked “unknown”. A plan made from such a working copy records its base commit and what differs from it. A plan made from code that has changed since, through another branch, a new commit or a removed source, can no longer be approved.
Documents attached to a session
Section titled “Documents attached to a session”Word files and PDFs you attach to a session are read as text, page by page. Images, and PDF pages without a text layer (scans), are read by a model. Each part of a document’s text says where it came from:
| Marked as | Meaning |
|---|---|
| The file’s own text | The text layer of the page, as written |
| Read by a model | Text a model read from the page’s image |
| Described by a model | A model’s description of what the page shows |
Search results and plans cite the page and this marking, so a model’s reading or description is never presented as the document’s own words. Up to 30 scanned pages per file are read; pages that could not be read are listed.
Nothing is executed
Section titled “Nothing is executed”WeHarness reads project files as text. It never installs dependencies, never runs package scripts such as postinstall or setup.py, never builds the project, and never follows links. During intake and indexing, a safeguard on our servers refuses any attempt to start a process.
Some facts can only be learned by running code; setup.py is an example. WeHarness reports those files as not evaluated and does not guess.
Disconnecting a source
Section titled “Disconnecting a source”Owners and admins can disconnect a source. Its content stops being readable in search and by tools immediately. A purge then deletes its stored text and everything derived from it. The source stays listed as disconnected, so the project’s history still makes sense.