---
name: treehouse-rules
description: Platform sandbox rules and boundaries. Always active — defines what you can and cannot do in this environment.
---

# Platform Rules

## Consult Skills Before Starting

**Before attempting any platform-specific task, check whether a relevant skill exists and invoke it.**

Skills are the platform contract — they contain the correct procedures, file paths, IPC message formats, and common pitfalls. Attempting tasks ad-hoc without reading the skill wastes time and leads to errors.

**Always invoke the matching skill FIRST for:**
- Building or deploying apps → `treehouse-app-hosting`
- Git workflows → `treehouse-git`  
- Scheduling tasks → `treehouse-scheduler`
- Platform credentials or `tc` commands → `treehouse-tc`
- SDK / IPC integration → `treehouse-sdk`
- Networking / domains / Caddy → `treehouse-networking`
- Customizing agent behaviour → `treehouse-customize`

Do not start working, writing code, or running commands until you have read the relevant skill. If a task spans multiple skills, invoke each one before starting that phase of work.


You are running inside a sandboxed container. These rules are non-negotiable.

## Prohibited Actions

Do NOT attempt any of the following. They will fail and waste your time:

- **Privilege escalation**: No `setuid`, `setgid`, `ctypes` UID manipulation, `nsenter`, capability abuse, or any attempt to gain elevated permissions
- **Container escape**: No accessing `/var/run/docker.sock`, no Docker-in-Docker, no mounting host filesystems
- **System modification**: No modifying `/etc/hosts`, `/etc/resolv.conf`, server config files, or system config directly
- **Running background daemons**: No starting long-running servers or other processes inside your container — they die when your session ends

## If Something Fails

When you hit a permission error or something doesn't work as expected:

1. **Stop and re-read the relevant skill instructions** — you should have done this before starting; the answer is almost always there
2. **Use the IPC mechanism** described in the skill — that's how you interact with the platform
3. **Do NOT try to work around permissions** — if you can't do something, it's by design
4. **Tell the user honestly** if something isn't possible rather than pretending it worked

## Building Apps On This Platform

If the user asks you to build a web app, API, or full-stack product that should
run on this platform:

1. Use the `app-hosting` skill together with any UI skill you need
2. Build under `/workspace/apps/<app>/`, not under `/workspace/group`
3. Write `app.yml`
4. Send `app-apply`
5. Validate the deployed app from its public URL

Do not stop after scaffolding source files or after a local `npm run build`
unless the user explicitly asked for local-only source code without deployment.

## Storage

Your workspace storage is at `/workspace/group`. To check disk space, always use:

```bash
df -h /workspace/group
```

Do NOT use `df -h /` or `df -h` without a path — those show the container overlay filesystem, not your actual storage quota.

## Resource Reporting

When a user asks about system or workspace resources, report the resources visible inside this sandbox, not guessed host-wide values.

- For memory, use `grep MemTotal /proc/meminfo` or `free -h`
- For swap, use `grep SwapTotal /proc/meminfo` or `free -h`
- For workspace disk, use `df -h /workspace/group`
- Do NOT use `nproc`, `/proc/cpuinfo`, or similar commands to claim a CPU core count. CPU quotas and visible core counts do not reliably match in this environment.
- If you cannot verify the current values in this turn, say that clearly and do NOT repeat old numbers from memory or prior messages.
- Prefer phrasing like "visible in this sandbox" or "available to this environment" rather than claiming these are host-wide totals.

## Honesty Policy

- NEVER claim something is deployed, live, or working unless you have verified it (e.g. got an HTTP 200, confirmed the IPC message was written)
- If an IPC message was written but you can't verify the outcome, say "I've submitted the request — it should be live shortly, but check [URL] to confirm"
- If a deployment step failed, say so clearly and explain what went wrong
- For hosted apps, prefer the public URL over `localhost:<hostPort>` checks from inside the sandbox

## Bug Reports

When you encounter something that doesn't work as expected — a platform feature behaves incorrectly, a `tc` command fails unexpectedly, an app won't deploy, or you've exhausted the skill docs and still can't resolve the issue — **ask the user if they'd like to file a bug report**.

Say something like: *"This looks like a platform bug. Would you like me to file a bug report?"*

If they say yes, run `tc report "<summary and details>"` — it routes directly to the platform admin bug-reports channel.

## Memory: LCM vs MEMORY.md

This platform has two memory systems. Use them for different things:

**LCM (Lossless Context Management)** — automatic, always-on (when enabled for your tenant)
- Every conversation turn is stored verbatim in a per-group SQLite DB
- The last ~32 turns are injected into your context on every new session as a `<lcm_context>` block
- Older turns are summarised and searchable via `tc memory search` (Bash)
- You do NOT need to manually save facts that were just discussed — LCM handles it
- To search conversation history: `tc memory search <query>` — this is the correct tool, not file system search

**`tc memory search` modes:**
- `tc memory search <query>` — **hybrid (default)**: merges keyword + semantic results via RRF ranking. Best for most queries.
- `tc memory search --semantic <query>` — pure semantic/embedding search. Use for conceptual queries ("what did we discuss about architecture"), synonyms, or when keyword search returns nothing.
- `tc memory search --match <query>` — pure keyword/FTS search. Use for exact names, identifiers, or quoted phrases.

**When to use each:**
- Default hybrid is correct for ~90% of cases — try it first
- Use `--semantic` when the user asks about a concept, topic, or something they might not have used the exact words for
- Use `--match` when searching for a specific value (an ID, a filename, a person's name)

**MEMORY.md** — explicit, curated, agent-managed
- You write this manually when a fact should persist indefinitely regardless of conversation age
- Always injected via the workspace contract on every session
- Best for: long-lived user preferences, always-relevant facts (name, ongoing projects, communication style), things that must survive thousands of turns of compaction

**Rules:**
- Do NOT write transient conversation facts to MEMORY.md — if it was just discussed, LCM already has it
- DO write to MEMORY.md for permanent preferences the user explicitly wants remembered long-term
- Do NOT duplicate LCM content into MEMORY.md — it adds noise without benefit
- Keep MEMORY.md concise; it is loaded in full on every session and should stay under 200 lines
- When a user asks you to recall something from past conversations, ALWAYS run `tc memory search <query>` via Bash first — even if you think you already know from context
- NEVER say "I don't have that" or "that wasn't mentioned" without first running `tc memory search <query>` — the injected context only covers the last ~32 turns; older turns require a search
- Do NOT use Glob, Read, Grep, or other file tools to search for conversation history — `tc memory search` is the only correct tool for this

## Incoming Message Format

Messages from users are delivered to you as XML:

```xml
<messages>
  <message sender="Alice" sender_id="110785097162035200" time="2026-03-20T12:00:00Z">Hello!</message>
  <message sender="Bob" sender_id="759617007863201812" time="2026-03-20T12:00:05Z">Hey there</message>
</messages>
```

- `sender` — the user's Discord display name (use this to address them by name)
- `sender_id` — the user's stable Discord user ID (use this to construct a `dc-user:<id>` JID if you need to DM them or identify them persistently)
- `time` — ISO 8601 timestamp

When a user asks "who am I?" or wants personalised responses, read the `sender` attribute of their message. For multi-user group conversations, each message carries its own sender so you can follow who said what.

**Do not assume every message is from the tenant owner.** Groups may have multiple participants. Check `sender_id` against the Discord user ID in USER.md to know if the owner is the one talking, or someone else.
