Fixing a bug needs evidence, but copying a whole application folder can mix much more than evidence. Source, runtime logs, login sessions and real manuscripts serve different purposes. Reviewing Northstar's source selection made me separate which files enter a development set from whether their contents are suitable for disclosure.

Define the folders needed for development first

SourceManifest starts from named source folders such as apps, packages, tests, sdk and docs plus selected root configuration files. It excludes profiles, secrets, release outputs, build outputs and dependencies. Path components containing .env are skipped, as are database, log and selected binary extensions.

That is more explicit than sweeping up every folder encountered during work. Names and hashes make the compared set inspectable. A hash only establishes byte identity, however. It cannot decide whether a document contains an account or a real manuscript. Allowed filenames are therefore one boundary; review of their actual contents remains another.

Do not trust a path merely because it looks internal

Inside rejects a relative path escaping the source root. RegularPath checks the root and successive path components for symbolic links, since a path appearing beneath a source folder can otherwise lead to unrelated material. Lexical containment alone would miss that relationship.

Candidate auditing also rejects unexpected top-level entries, environment files and runtime-data extensions. Individual source files have a size bound. These checks describe a specific development-candidate boundary, not certification against every filesystem attack. Reviewing the function also does not mean opening or inspecting a person's operational login folder. The evidence is the implemented selection rule and the files actually reviewed.

An executable payload is a different set from user data

Rollback payloadManifest enumerates runtime binaries and resources, permitted locale files and specific MCP files. It does not create a restore installer by copying the whole user-data store. If part of the MCP bundle exists, required companion files must exist too; unexpected payload entries are rejected rather than silently included.

The associated fixture checks a modified hash and a missing MCP file. An added synthetic token.json is refused as unsupported payload. That is not publication of a real token or a complete audit of authentication storage. Payload completeness and retained account sessions concern different material sets and need different evidence.

A connection token is not a shared development convenience

Current external MCP documentation says not to print, commit or copy the local connection token. Actual machine paths stay in host configuration outside source. A runnable example can describe the contract without embedding this computer's authenticated discovery data.

The installed product has also removed embedded CLI and repair runtime and now hosts execution for an external conversation. Describing a retained historical source-selection function must not imply that the current app automatically sends source to an internal model. A useful account distinguishes the old material boundary from the paths still connected in the product today.

Share the selection rationale rather than a copied workspace

For public modules I reconstruct the necessary idea with synthetic inputs instead of publishing a workspace copy with a few authentication files removed. Original evidence remains in a private ledger with reviewed ranges and hashes. The public explanation transfers selection rules and failure conditions without transferring customer material.

Passing a filename filter never establishes public safety by itself. Comments, documents and examples still need a final content read. This article rests on source and existing fixture review, with no fresh install or login extraction. The maker should be able to explain both why the evidence is sufficient and exactly what material was included to reach that judgment.