Projects
Open in product: preshos.com/agent-ops — Projects live in Agent Ops history, not on a separate route.
A project is a personal standalone grouping in Agent Ops history: a named place where your sessions on one line of work stay together. Projects are scoped to tenant plus user — your projects are yours, on your tenant, and nobody else’s sessions land in them.
On Local, the folder is the project
Section titled “On Local, the folder is the project”On a Local run target there is no separate project object to create first: the folder is the project. Point the session at a folder with Open folder… or start fresh with New project…, and that folder carries the line of work — persistent working state plus the project’s private indexed context. Chats that never pick a project still get a home: each projectless chat gets a per-session folder under ~/PRESHos/YYYY-MM-DD/<chat>, so follow-up runs start from the same working state instead of rediscovery.
- Persistent desktop folder. Each project keeps a folder that survives across sessions, so follow-up runs start from the same working state instead of rediscovery.
- Private indexed context files. Upload reference material into the project and it is ingested through a search pipeline the project’s sessions can draw on. Context files are private to the project owner.
- Optional work-item link. A project may link to one authorized work item, tying the line of work to tracked work. The link is optional — unlinked projects behave as before.
Cloud runs: which environment applies
Section titled “Cloud runs: which environment applies”Cloud sessions resolve their environment in order: an explicit choice in the composer wins; otherwise the project’s environment applies, then a GitHub remote match, then the Default environment. Environments are execution targets picked through the Run target menu — they are no longer objects in the history rail, so history groups sessions under projects, not environments. Treat the product UI as the source of truth for the exact preselection shown.
How sessions resolve to projects
Section titled “How sessions resolve to projects”Starting a session on a work item that descends from a project-linked item resolves to the nearest project owned by the current user. Unscoped plans behave as before — no project is attached, and nothing about the session changes.
- Private context never enters shared sessions. Project retrieval rechecks record and field permissions at read time. A session another member can see never receives your private project context, even when the work item overlaps.
- History groups sessions under their project, with pin, hide, archive, and context-menu actions on groups. Treat the product UI as the source of truth for the exact menu labels.
Preferences and bindings
Section titled “Preferences and bindings”Projects, history preferences, and folder bindings are scoped to tenant plus user. Switching tenants or users changes which projects are visible — same rule as threads: session records are not portable across tenants.
What next
Section titled “What next”- Starting a session: the Run target menu — Local folder vs Cloud environment — that opens a project-scoped session.
- Threads: the message-and-action line each project session carries.
- Sessions: the open-session surface once project work starts.
- Working folder vs artifacts: scratch state against reviewable outputs inside the project folder.