The directory is the single place where every active project lives as a tree — and the place each project's Pat conversation starts from. It is a shared surface: the owner sees everything, a collaborator sees only what has been shared with them, and both read the same live data.
Numbers are permanent identifiers: a new requirement takes the next free number and is shown alongside the ones it belongs with, rather than renumbering what came before. Requirements marked live are implemented and running today. owner-only marks capability that is deliberately not extended to collaborators.
The tree
FR-1 → FR-8 · FR-21 Structure, and the edits that keep it true.FR-1
Projects live in a nested treelive
Projects are grouped into named branches, and branches may contain sub-branches to any depth (e.g.
CRRE › JBR › JBR-FIN). Each branch shows a live count of its active projects.FR-2
Every project carries a hashtag codelive
A short uppercase code (
#JBR-FIN) is the project's identity — the handle used in conversation with Pat, in memory, and across every other system. Codes are unique and renameable in place.FR-3
Project metadata is visible at a glancelive
Icon, name, status (live / active / build), a link to the live system and an optional second link to its dashboard, plus a description and tech stack on hover.
FR-4
Projects can be added from the branch they belong tolive
A
+ Add control on each branch opens a form for icon, name, code, status, URL, description and tech tags. The form stays open and says why if the save does not reach the server — it never closes on an unsaved change.FR-5
Projects can be re-homed by dragginglive
Drag a project onto another branch to move it, or between two projects to reorder it. The new position is persisted immediately.
FR-6
Finished projects archive rather than disappearlive
Archiving removes a project from the active count and the default view; each branch offers a show/hide toggle that reveals its archived projects on demand. Archiving is reversible.
FR-7
Deletion is explicit and confirmedlive
Removing a project asks first. Archiving — not deletion — is the normal end of a project's life.
FR-8
Large trees stay readablelive
Top-level branches are collapsed by default, sub-branches open; expand-all and collapse-all are one click, and each viewer's expand state is remembered on their own device.
FR-21
Folders are created, renamed and removed from the page itselfnew · 15 Sep 2026live
Any branch offers
+ Folder to create a folder inside it (to any depth), and the toolbar offers one at the top level. A folder takes a name, an auto-derived tag and an optional description; it is immediately open and ready to receive projects by drag or by its own + Add. Renaming keeps the folder's identity, so nothing a viewer has expanded or revealed is disturbed. Removing a folder never removes what is in it — a folder holding anything refuses to be deleted and says what to empty first, because the tree is the only record of where a project lives.Working with Pat
FR-9 → FR-11 · FR-22 → FR-23 The directory is where a project's conversation begins.FR-9
One click copies a ready-to-paste instructionlive
Clicking a
#CODE chip copies Pat, let's work on "…" (#CODE). Load its CLAUDE.md, memory, and current state… — so any chat with Pat can be brought up to speed on that project without typing anything.FR-10
💬 opens a fresh Pat chat already pointed at the projectlive
Opens a new Pat session with that project's instruction pre-filled and the tab titled with the project name — the chat starts loaded rather than empty.
FR-22
A folder has a hashtag of its own, meaning everything inside itnew · 15 Sep 2026live
Every folder carries its own
#TAG chip and 💬 button, exactly as a project does — but scoped to the whole area. Clicking it copies Pat, let's work on the "JBR" folder (#JBR). It covers 8 projects: #JBR-SYNC, #JBR-BONUS, … Load each one's CLAUDE.md, memory, and current state, then summarize where this whole folder stands and what's next across it. Nested folders are included, archived projects are not, and an empty folder says so instead of asking Pat to load nothing. All hashtags share one namespace — a folder tag cannot collide with a project code or another folder's tag, because #X has to resolve to one thing when it is pasted into a chat. Chat search (FR-13) files folder-level conversations under that folder, alongside the projects it covers.FR-23
Renaming a code keeps the old one pointing at the projectnew · 16 Sep 2026live
When an area outgrows a single project, its hashtag belongs to the folder and the project takes a narrower code of its own —
#USRE → folder, #USRE-FIN the reconciliation app; likewise #USHAIA-WEB, #ELNIDO-WEB, #CLINCAPTURE-GOV. A rename is refused if the new code is already a project code or a folder tag (FR-22), and the retired code is kept on the project as an alias, so every conversation that opened with (#OLDCODE) still files under it in chat search. Going forward the hashtag means the folder: a chat that merely mentions #USHAIA is a folder-level chat, while a chat that opened with the project hand-off prompt stays with the project.FR-11
The toolbox behind the projects is publishedlive
A Skills section lists the capabilities Pat invokes on demand, so a reader can see what the assistant behind these projects can actually do.
Search across chats
FR-12 → FR-14 · FR-24 Find the conversation, not just the project.FR-12
Keyword search runs across every project chatnew · 15 Sep 2026live
A search box on the directory searches all chats of all projects at once — both Pat web sessions and Claude Code sessions. Several words may be given; a chat matches when a single message contains all of them. Only what was actually said is searched: tool calls, tool output and internal reasoning are excluded, so a keyword that merely appeared inside a file Pat happened to read is not a hit.
FR-13
Results come back as the sections of the directory they belong tonew · 15 Sep 2026live
Matches are attributed to a project and returned grouped by the section of the tree that project lives in (
CRRE › JBR, AI Infrastructure, …), ordered by how much of the keyword each section holds. Under each project sit the matching chats, each with dated, highlighted excerpts and a count of further matches. Chats that mention the keyword but carry no project tag are returned separately rather than dropped. Clicking a result's project name opens that branch in the tree and highlights the project.FR-14
A result opens the chat it came fromnew · 15 Sep 2026live
A web-chat result links straight into that conversation at
pat.gicqueau.com, reopened with its full history. A Claude Code result exposes its session id to copy, since those sessions are resumed from the terminal.FR-24
A result opens a new Pat chat that already knows the keywordnew · 16 Sep 2026live
Every project and folder in the results carries its own 💬, which opens a fresh Pat chat in a new tab, pre-filled with the project's hand-off (FR-9) and what was being searched for:
Pat, let's work on "Statements Download" (#STMTS). Load its CLAUDE.md, memory, and current state. I was searching my chat history for "4432" — it comes up in 11 of this project's conversations (Sep 2026). Find what those chats say about "4432", then tell me where that stands now and what is still open. The hit count and the date span come from the result itself, so the conversation starts knowing how much there is to find; a folder result uses the folder's wording and lists the projects it covers. The instruction is copied to the clipboard as well as sent, so a blocked pop-up still leaves it in hand.Access & privacy
FR-15 → FR-17 Who sees what — and what is never shared.FR-15
Every viewer is authenticatedlive
The directory and its API both sit behind an email allow-list. There is no anonymous read path and no unauthenticated back door to the data.
FR-16
A collaborator sees only the projects shared with themlive
The tree is filtered per signed-in identity before it leaves the server — branches that end up empty are pruned — and collaborators have read-only access. The filtering fails closed: if the share list cannot be confirmed, the answer is nothing, never everything.
FR-17
Chat search is owner-onlyowner-onlylive
Chat transcripts are raw working sessions — credentials, legal matters, personal and other clients' material — and cannot be meaningfully narrowed to "only the parts about the projects you were granted". Sharing a project therefore shares the project entry, never its conversations: a collaborator's search request is refused outright rather than answered with a reduced result set.
Data integrity
FR-18 → FR-20 Hard-won rules. Each one exists because it was once broken.FR-18
The tree is stored server-side and shared across deviceslive
One canonical copy on the server; phone, laptop and Pat itself all read and write the same tree. A local copy is kept only as a read-only fallback for when the network is down, and is refreshed on every successful load so it can never resurface as stale truth.
FR-19
Concurrent edits cannot silently overwrite each otherlive
Every write carries the version it was based on. A stale write is rejected, then retried once against the current version with the edit reapplied — a tab left open for a day cannot clobber the tree, and a rejected write is never quietly discarded.
FR-20
Nothing fails silentlylive
A save, a search or a load that does not land says so, in plain language, with what happened and what to do next. The interface never reports success it has not actually confirmed.
Why this is a requirement and not a nicety
- Writes silently no-oped for days behind a new authentication layer; the page looked like it had saved.
- A version conflict once discarded the edit instead of reapplying it — a project vanished on the next refresh.
- A failed load once fell back to a built-in seed, showing a collaborator the full project list.