Glass Box guide

The agent harness: what a session reads, runs and may start.

• CLAUDE.mdThe one file every session reads first, kept short enough to follow.
• Path-specific rulesInstructions that load only with the files they are about.
• Claude Code SkillsA folder of steps for one job, read only when the job comes up.
• Claude Code hooksCommands Claude Code runs at fixed points, whatever the model decides.
• Blocking hooksHooks that refuse a wrong tool call and say what to do instead, and why one that crashes must block too.
• Hook-added contextHooks that add guidance beside a tool's result or a prompt, never block it, and say each thing once.
• SubagentsBlank-context helpers that do part of a session's work and report back.
• MCP serversOutside systems, such as GitHub, reach a Claude Code session as tools over one protocol.
• Workflow scriptsA script that runs many subagents in a fixed order the model can't skip, kept in `.claude/workflows/` for one Skill.
• Scheduled tasksPrompts Claude Code runs again later, in the cloud, on your machine or inside one open session.
• Cloud sessionsWhat a Claude Code session in the cloud starts with and what it can reach.
• Claude Code permissionsSettings files, allow, ask and deny rules, and the permission mode decide which tool calls run without asking.

Outside Skills the agents plan and build with.

• Skill packsA set of Skills written elsewhere and installed into the repo, and how Terrarium keeps them as installed.
• Engineering skillsThe Skill pack's Skills for building and checking a change, and the one Terrarium makes a fixed step.

One app, one page file, many sites.

• Nuxt layersFolders that each add pages, components and config to one Nuxt app, merged at build.
• File routingEach page file's path is its URL, and the most specific match wins, down to a catch-all.
• Virtual modulesHow a Nuxt module computes data before the app runs and hands it to code as a typed import, like #routing.
• Auto-importsHow Nuxt lets code use components, composables and utils without an import, in one shared set of names.
• Vue componentsSingle-file components, refs and composables, and how a Vue page is built from them.
• Data fetchingLoad once on the server; a click reads the payload the server rendered.
• CSS custom propertiesValues named once on a wrapper element that every component inside inherits, and how each Tenant themes its pages.
• HydrationWhy the server's render and the browser's first must agree, and how to show the browser's value only after mount.
• Nitro server engineThe engine that serves each request, applies the page cache and builds the server.

Files to tables: collections, isolation, the database.

• Content collectionsGroups of content files of one kind, each with its own schema and table.
• Multi-tenant isolationKeeping each tenant's data in a store of its own, so no query can return another tenant's.
• Content databaseSQL dumps at build, SQLite on the server, WebAssembly in the browser only when needed.

The merge gate and its checks: types, content, tests.

• Merge gateA fixed set of machine checks every change must pass before it merges.
• Type checkingHow a type checker picks the files it checks, and why a Nuxt app needs vue-tsc.
• Content validationRunning content files through their schemas, which Nuxt Content uses only for column types.
• TestingFast unit tests and browser tests on one shared build, each site keeping its own.
• LintingRules about how code is written, checked one file at a time, for problems that still pass a type check.
• Zod refinementsChecking a config file with Zod refinements, so one run lists every problem before anything is built.
• Timestamps stored as stringsWhy a z.date() field loses its time of day in Nuxt Content, and how a refined UTC string keeps the instant.

One container that builds and swaps main.

• Continuous deploymentEvery merge goes live by itself, and only a build that worked replaces the live site.
• pnpm and the lockfileA committed lockfile pins every package to one exact version, so CI and the server install the tree you tested.

Pull requests, worktrees and who may direct an agent.

• Pull requestsA proposal to merge one branch into another, reviewed and checked before it lands.
• Git worktreesExtra working folders of one repository, so parallel agents never share a checkout.
• Composite actionsKeep a CI workflow file to a thin shell and move its steps into a composite action that agents can change.
• Author trustWho may direct an agent comes from GitHub identity, never from the text.
• Commit and PR attributionMarking each agent write with the session that made it, when the agent posts and commits as a person.
• Issue triage labelsHow Terrarium uses GitHub issue labels as the queue agents take work from, and who may mark an issue ready.
• Dependabot groupingHow Dependabot groups fold many updates into one pull request, and which grouped bumps an agent may merge.

Decision records, session logs, required reviewers.

• Human-in-the-loop agentsPeople decide what gets built and keep the merges no check can judge; agents propose freely and build what was approved.
• Decision recordsOne short record per decision, rewritten in place when it changes.
• Ubiquitous languageOne shared glossary for the words every agent needs, one per Tenant for the rest, and a map that ties them together.
• Session logsA record each agent session leaves of its work and of every problem it hit.
• Out-of-scope recordsHow Terrarium writes down a rejected idea once, so the next request for it meets the old reasons.
• Protected pathsFiles that need a person, read from the target branch so no change can unlist itself.
• Cross-tenant readsLetting a few views read every tenant's data, but only the named shapes each tenant chose to offer.
• Self-improvement loopA process that improves itself as problems are grouped by cause, fixed and rechecked later.