3. Using SPEAR

The day-to-day surface: the chat and its commands, the corpora it answers from, how retrieval and the context window are managed, and every setting that changes them.

• 3.1. spear-chat
  • 3.1.1. The corpus is the unit
  • 3.1.2. Permission modes
  • 3.1.3. Command line
  • 3.1.4. In-chat reference
  • 3.1.5. Web access
  • 3.1.6. Knowledge layers, on different clocks
  • 3.1.7. What a turn is allowed to do
• 3.2. Projects and corpora
  • 3.2.1. The registry
  • 3.2.2. Entry format
  • 3.2.3. Normative checks and applicability
  • 3.2.4. What a turn is shown
  • 3.2.5. What a build command proves
  • 3.2.6. Exclusions have granularity
  • 3.2.7. Choosing a corpus for a session
  • 3.2.8. Writable roots
  • 3.2.9. Indexing
• 3.3. Retrieval
  • 3.3.1. Corpus
  • 3.3.2. Projects
  • 3.3.3. Federated and shared corpora
  • 3.3.4. Corpus and workspace are two roots, not one
  • 3.3.5. Prompt assembly
  • 3.3.6. Workspace knowledge
  • 3.3.7. Embedding on another machine
  • 3.3.8. Retrieval budget
  • 3.3.9. Orientation maps
• 3.4. Conversation context and history
  • 3.4.1. Scope is read from the current message
  • 3.4.2. Self-contained and referring turns
  • 3.4.3. Why prior implementation detail is not authoritative
  • 3.4.4. Practical consequences
• 3.5. Workspace knowledge
  • 3.5.1. What it is not
  • 3.5.2. Recording knowledge
  • 3.5.3. Inspecting and removing it
  • 3.5.4. What a turn is shown
  • 3.5.5. Legacy remembered notes
• 3.6. External capabilities
  • 3.6.1. Registering a provider
  • 3.6.2. What a turn is offered
  • 3.6.3. What a provider says is data
• 3.7. Configuration reference
  • 3.7.1. Files
  • 3.7.2. Endpoint and model
  • 3.7.3. Corpora and retrieval
  • 3.7.4. Authoritative standards
  • 3.7.5. Permissions and execution
  • 3.7.6. Session state and audit
  • 3.7.7. Not configuration