The previous note in this thread argued that operational truth should remain where it can be validated: repositories, runtime systems, GitHub history, review evidence, and human judgment.
That leaves a practical question for AI-assisted engineering:
What should happen before the first implementation proposal?
My recent local sessions point to a simple answer. Every session should begin by establishing the current operational boundary.
That boundary is not another source of truth. It is the working edge around the current task. It tells the assistant where it is, what it is allowed to assume, what evidence already exists, and what should not be crossed without explicit intent.
Without that boundary, the assistant may still produce plausible work. The problem is that plausible work can land in the wrong repository, target the wrong branch, repeat work from a previous session, expose private context in a public place, or treat temporary chat state as durable engineering memory.
Why Session Starts Matter
AI-assisted engineering often begins in the middle of something.
A pull request was merged. An issue needs follow-up. A deployment question spans several repositories. A previous session already tested part of the answer. The current checkout may be clean, dirty, behind its upstream, or not the authoritative repo at all.
In those situations, "start coding" is not the first useful action.
The first useful action is orientation:
Where am I?
Which repository owns this work?
Which branch is active?
What issue or objective defines the task?
What prior local work matters?
What evidence should I inspect before acting?
What boundaries should remain closed?
This is not ceremony. It is an execution constraint.
Local sessions from late June and early July repeatedly followed this pattern. Work began by checking the repository path, branch, dirty state, repo guidance, issue or pull request context, and recent related sessions. When the task started from GitHub, the first move was usually read-only inspection. When repo guidance was missing, the session recovered from the README, workspace guidance, issue history, and local audit output before proposing changes.
The pattern was consistent across coding work, GitHub follow-up, documentation drafting, and operational review. The assistant became more useful after it knew the boundary.
The Operational Boundary
An operational boundary is the minimal current context needed to execute responsibly.
It usually includes:
- the authoritative repository
- the active branch and worktree state
- the issue, pull request, or explicit objective
- repo-owned guidance such as README files, agent instructions, workflow docs, manifests, and generated context
- relevant recent local sessions
- available capabilities and unavailable connectors
- explicit limits such as read-only, no-post, no-push, public-only, or repo-only work
The boundary is deliberately smaller than the whole knowledge base. It does not ask the assistant to load every memory, every old transcript, or every possible workflow note. It asks the assistant to recover enough context to avoid making the first wrong move.
That distinction matters.
Session start establishes context.
It does not establish truth.
Truth still belongs to the repository, the runtime, the review record, the issue history, the deployment system, and the human decision. The session boundary only tells the assistant which of those sources should be consulted before acting.
Recovering Context Instead Of Recreating It
The strongest recurring pattern in the local evidence was recovery.
Good sessions did not recreate the world from the prompt. They recovered it from existing sources.
When a task began from an issue, the issue defined the work. When a repo had local guidance, the repo guidance shaped the workflow. When a branch had uncommitted changes, the session treated them as existing user state. When recent sessions existed for the same repo, they were treated as continuity hints, not as authority. When a repo lacked a local instruction file, the assistant did not invent a contract. It moved outward to the README, workspace instructions, and the issue trail.
This reduces ambiguity without freezing the work.
The assistant can still propose a creative implementation, but it does so after learning the shape of the system it is operating inside. The boundary does not remove judgment. It gives judgment something to attach to.
It also prevents a common failure mode: solving a remembered problem instead of the current one.
Recent sessions are useful because they preserve continuity. They can show that a similar issue was handled, that a command failed in a particular way, or that a workflow convention was refined. But they are not the owning source. A previous session can suggest what to inspect. It cannot replace the current branch, current issue, current repo contract, or current runtime evidence.
Session Context Is Temporary
Session context is working memory.
It can include the current prompt, local command output, the fact that the branch is dirty, the issue reference for the current task, a note that the user said not to post yet, or a reminder that a connector is unavailable in this session.
Most of that should not become long-term memory.
Temporary context is valuable because it protects the current execution. It becomes harmful when it is promoted too easily. A private issue number, a one-off branch state, an incomplete test result, a current deployment snapshot, or a local workaround can be useful inside a session and still be wrong as durable memory.
The local guidance evolved toward this rule:
Preserve patterns, not residue.
A recurring GitHub command failure with a proven fallback can become a gist note or skill reference. A repeated repo workflow gap can become repo documentation. A stable personal preference can become memory. A public engineering pattern can become an article.
But raw transcripts, volatile PR state, private customer details, temporary local output, and one-off implementation guesses should usually expire with the session.
Operational Truth Remains Elsewhere
This is where session context, engineering memory, and operational truth fit together.
Session context is temporary orientation for the current execution.
Engineering memory is promoted learning that helps future executions.
Operational truth is the evidence-bearing source that can be checked.
They are complementary, not competing concepts.
Session context helps the assistant avoid immediate ambiguity. Engineering memory helps future sessions recover durable patterns faster. Operational truth keeps both of them grounded.
The repository remains the primary shared surface for implementation truth. GitHub remains the shared record for issues, pull requests, reviews, and workflow history. Runtime systems remain the place to verify operational behavior. Human intent remains human-owned, especially when a task crosses public/private boundaries or changes external state.
The session boundary connects those sources. It should not replace them.
Practical Observations From Daily Engineering Work
Several observations repeated across the recent work.
First, issue references matter early. When a session begins inside a repository but no issue or objective is present, asking for the issue reference is not bureaucratic. It prevents the assistant from treating a checkout as the task definition.
Second, repository selection is an engineering decision. Several tasks referenced one repo while depending on another. The reliable behavior was to confirm the current repo boundary and avoid crossing into adjacent repositories unless the user explicitly requested it.
Third, dirty state changes the risk profile. A clean branch invites normal implementation. A dirty branch requires care, because existing changes may belong to the user or to earlier work. The session boundary has to include that state before edits begin.
Fourth, read-only boundaries need to be honored as hard constraints. "Research first," "do not post," and "do not push" are not tone preferences. They define the current execution mode.
Fifth, public and private knowledge need different handling. A private issue can guide local work, but it should not leak into a public pull request. Public descriptions should contain reviewer-useful evidence, not private context or noisy local logs that duplicate CI.
Sixth, repo-owned context should be repaired at the repo layer. If the README, workflow docs, manifests, or generated context are missing or contradictory, the durable fix belongs there. Global assistant instructions should route the workflow, not absorb the repo's current facts.
Seventh, recent sessions are useful as recovery hints. They help answer "what were we doing?" They should not answer "what is true now?" without a fresh check against the owning source.
Toward Bounded Automation
The point of a session-start boundary is not to make AI cautious in the abstract.
The point is to make execution reproducible.
When a session begins by recovering the authoritative repo, branch, issue, recent continuity, available capabilities, and explicit limits, the next steps become easier to inspect. Another human or assistant can understand why the work moved in a particular direction. A later session can recover the same boundary and check whether the same evidence still holds.
That reduces hallucination because the assistant is not asked to invent the operating model from the prompt. It reduces drift because temporary context is not promoted automatically. It preserves creativity because the assistant can still explore solutions inside the right boundary.
Bounded automation is not smaller automation. It is automation with an explicit operating edge.
The session start is where that edge is drawn.