# Session & Chat Protocol All working sessions within the Life Enterprise System (LES) are conducted through structured Claude chat sessions. Each session type has a defined purpose, scope, and output. This page describes the session protocol: what types of session exist, when each is used, and what each session produces. The session system is governed by the principle that Claude sessions are temporary working environments, not archives (Decision 27). All session outputs that need to persist — decisions, code, documentation, journal entries — are committed to GitHub or published to GitBook during or immediately after the session. *** ### Chat Session Codes Every session is identified by a code that communicates its type and purpose. The code appears in the session heading and, where applicable, in commit messages and document references. | Code | Session Type | Purpose | | ---------------------- | --------------- | ------------------------------------------------------------------------------ | | `LES-MENTOR` | Home base | Progress reporting, context updates, next step assignment, end-of-week rituals | | `LES-ROADMAP` | Master planning | Phase reviews, roadmap updates, long-range planning decisions | | `LES-SETUP` | Configuration | Account creation, platform configuration, first-time setup steps | | `LES-LEARN-[topic]` | Learning | Deep learning sessions — one topic per session | | `LES-BUILD-[module]` | Building | Module and feature building sessions | | `LES-WEBSITE-[number]` | Website | Website build and content sessions, numbered sequentially | | `LES-DOCS` | Documentation | GitBook and LinkedIn content creation | | `LES-RESEARCH` | Research | Academic research sessions | | `LES-REVIEW` | Review | Progress reviews and retrospectives | *** ### LES-MENTOR — Home Base `LES-MENTOR` is the central coordination session. It is the session type that holds the master context document and from which all other session types are assigned. **When to use:** At the start of any significant working period. When returning from another session type with output to report. When running the End of Week ritual. **What it produces:** * Updated master context document * Assignment of next session type and topic * ADR file (at end of day) * Journal entry (at end of week) * Documentation Briefing at close of every session **The master context document** (`_context/master-context.md` in LES-Master) must be pasted at the start of every new LES-MENTOR session. This is the mechanism by which continuity is maintained across sessions. *** ### Session Scope Rules Each session type has a defined scope. Scope boundaries are respected in both directions: * Work that belongs in a different session type is not performed in the current session. It is noted and redirected. * A new session of the appropriate type is opened for that work. This discipline prevents scope creep within sessions and ensures that every session produces clean, categorised outputs. *** ### Documentation Briefing Every session closes with a Documentation Briefing. This is produced by Claude at the end of every session and covers: 1. **ADRs to write** — a list of decisions made during the session that require a formal ADR entry 2. **Journal entry** — a summary suitable for inclusion in the weekly journal 3. **GitHub commits required** — what needs to be committed, to which repository, and with what commit message 4. **GitBook publications required** — what content needs to be published, to which section The Documentation Briefing is the handover document between the working session and the documentation session. Nothing is lost between sessions because everything requiring documentation is explicitly named. *** ### End of Week Ritual The End of Week ritual is triggered in `LES-MENTOR` by the phrase "finalise week." **Protocol:** 1. All completed tasks across all sessions that week are reported 2. The master context is updated — tasks ticked, decisions added, checklist updated 3. The ADR file is written for the day — all decisions grouped by subject in one dated file 4. A weekly journal entry is written — covering all sessions across all days that week 5. A decision is made together: does this week's journal warrant a GitBook publication? 6. All files are committed to GitHub **ADR file format:** * One file per day: `ADR-YYYY-MM-DD.md` * Sections: Architecture Decisions, Strategic Decisions, Technology Decisions, Operational Decisions * Each entry: decision statement and rationale. Full alternatives and consequences for high-impact decisions only. * GitBook: Yes/No flag on each decision **Journal entry format:** * One entry per week — covers all sessions across all days that week * Document code: next available `LES-JOUR-000[NNN]` * Published to GitBook when content is substantial, standalone, and reader-facing **Commit message format:** `LES-MENTOR Week [N] — End of week — [brief summary]` *** ### Learning Sessions — LES-LEARN-\[topic] Learning sessions are structured as guided instruction. The session code identifies the topic, for example `LES-LEARN-AZ900` for Azure fundamentals or `LES-LEARN-GH` for GitHub. Learning sessions follow the governing principle of the project: no shortcuts, no surface-level coverage, full understanding before moving forward (Decision 6). Every term is explained before it is used. Every step is written out completely. Learning sessions may produce: * Structured lesson content * Exercises and questions * A homework assignment * A concept documented for potential GitBook publication *** ### Build Sessions — LES-BUILD-\[module] Build sessions are the working sessions in which LES modules and features are constructed. The session code identifies the module, for example `LES-BUILD-FIN` for the Finance module. Build sessions follow the principle that every architectural decision is recorded before implementation begins. No code is written without a prior understanding of what it does and why it is the right approach. Build sessions produce: * Code committed to the appropriate repository * Architecture and design documentation * ADR entries for decisions made during the build * Specification updates where the build reveals a need to refine the design *** ### Documentation Sessions — LES-DOCS Documentation sessions are dedicated to producing reader-facing content: GitBook pages, LinkedIn articles, and other portfolio publications. Portfolio content is never produced autonomously. GitBook entries and LinkedIn articles are drafted only when explicitly requested, at the defined trigger points described in the Governance Framework Overview. *** ### Related Pages * Document Taxonomy & Coding System * Governance Framework Overview * Decision Log Overview * **GitHub:** [github.com/NikiDigitals](https://github.com/NikiDigitals) * **Website:** [nikidigitals.com](https://nikidigitals.com) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://nikidigitals.gitbook.io/les/02-project-governance/session-and-chat-protocol.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.