Plan follow-up work after the workspace Files browsing foundation #201

Purpose

Track the work that may follow the minimal workspace Files browsing foundation without expanding the durable ADR into a multi-system implementation plan.

The accepted decision belongs in docs/internals/scient-workspace-file-visibility.md. This issue owns deferred investigation and sequencing. Its checklist is not blanket authorization to implement every item: each slice still needs evidence, a clear owner, and proportionate acceptance criteria.

Foundation this follows

The first foundation should remain deliberately small:

• useful project files, including dotfiles and Git-ignored material, are visible in ordinary Files;
• exact known machinery stays quiet by default and is available through deliberate, lazy internal inspection;
• unknown in-workspace paths fail open to ordinary visibility;
• directories are enumerated one branch at a time;
• managed or tool-owned internals are read-only in generic Files;
• Files visibility does not change provider filesystem authority or preload model context.

Deferred work

Filename discovery

• Benchmark the existing FFF path index, bounded query-time traversal, and a lightweight metadata index against representative code, academic, scientific, and remote workspaces.
• Choose one long-term filename-discovery mechanism. Avoid permanently operating both the legacy path index and a second Files-only index.
• Make project-wide filename discovery include every ordinary-visible path, including eligible Git-ignored material.
• Report complete, partial, and failed search scope truthfully.
• Migrate existing consumers deliberately: desktop Files, file picker, composer path discovery, and mobile.

Content search

• Define content-search eligibility independently from tree visibility and Git ignore state.
• Set evidence-backed type, size, time, result, cancellation, and byte budgets.
• Decide how sensitive files and raw managed stores are excluded or deliberately searched.
• Expose incomplete or excluded scope without implying complete project coverage.

Composer and model-facing actions

• Decide when sensitive paths appear in composer suggestions.
• Design concise confirmation for deliberately adding a likely-sensitive path.
• Keep the explanation exact: a file mention adds a path reference; provider access follows the active workspace and permission model.
• Verify that changing Files visibility never broadens model context automatically.

Managed project data

• Add narrow Inspect stored files actions from owning surfaces where raw evidence is useful.
• Improve Sources presentation of provenance, revision history, import receipts, and attachment identity when that meaning is not clear from the current owner surface.
• Apply the same owner-surface versus raw-inspection rule to Skills and any later subsystem that stores durable project data.
• Add compute-specific workspace policy only if compute begins writing inside project roots; current compute sessions live in application state.

Freshness and scale

• Measure unusually large single directories before selecting pagination or continuation mechanics.
• Add branch change hints, watcher-overflow recovery, reconnect refresh, focus refresh, and remote-latency optimizations only where observed behavior requires them.
• Preserve selection, expansion, and focus while affected branches refresh.
• Benchmark payload size, latency, memory, and client update cost on representative workspaces.

Mobile and shared clients

• Keep legacy flat listing available until every consumer is identified.
• Decide whether and when mobile adopts the directory contract based on its own UX and performance constraints.
• Remove legacy contracts only after all consumers are migrated and verified.

Policy governance and documentation

• Require any subsystem that hides a project path to own an exact rule, rationale, and fixture.
• Keep generic names such as data, results, output, cache, or history visible unless an exact owner rule says otherwise.
• Review new project-local .scient storage when it is introduced; do not invent speculative hidden paths.
• Update the owning user documentation with each released behavior and include the required documentation-impact declaration in every PR.

Decision gate for each follow-up

Before implementing any item above, establish:

1. the user problem and observed evidence;
2. why the smallest existing mechanism cannot solve it;
3. the minimum new state or contract required;
4. failure, rollback, and compatibility behavior;
5. representative fixtures or benchmarks;
6. upstream T3 conflict surface;
7. the documentation owner.

Work on one bounded slice at a time. The existence of this issue should prevent forgotten follow-ups, not turn every possible improvement into a prerequisite for the Files foundation.