Practical use.
Context depth should follow the size of the next action. A one-file fix rarely needs a project-wide history dump; a cross-module design change may need more than the last chat turn.
4-Tier Context.
ShardStitch chooses the right context depth: session, task, project, or everything, instead of forcing one oversized blob into every handoff.
What it carries.
- Session-level hot context
- Task-level working state
- Project-level memory
- Deep recovery when the situation demands it
How it fits ShardStitch.
This feature describes context scope: carry the smallest useful layer first, then expand into files, history, dependencies, and decisions only when the task requires it.
When to use each tier.
Use session context for a small continuation, task context when one feature spans several files, and project context when architecture or conventions affect the next edit. The deep tier is reserved for recovery cases where a broader dependency or decision history changes the safe action. This keeps a handoff inspectable instead of making every restart carry the same oversized transcript.
The tier is a selection decision, not an automatic claim that every file matters. ShardStitch records the chosen scope so the next AI can see what was included and what still needs checking.
Choose the smallest useful context tier.
For a narrow continuation, start with the session or task layer. Expand toward project history and broader repository context only when the next action crosses those boundaries.
- Use session context when the next action is a direct continuation and the changed files are known.
- Use task context when the work spans several files or depends on decisions and failed approaches from the current task.
- Use project or deeper context when architecture, conventions, or earlier decisions affect the proposed change; trim back to relevant evidence before handoff.
Worked example.
If the next action is to fix one failing test, the current task and its changed file may be enough. If that test depends on a design choice made earlier, include the project-level decision and its source. Avoid sending the entire project history by default; expand the tier only when a concrete dependency or unresolved decision requires it.
Limits and verification.
The tiers are a selection aid, not a universal token budget or a quality score. The smallest packet is not always sufficient: if a decision depends on broader architecture, include that evidence explicitly instead of forcing a narrow summary.