Skip to content
familiarfamiliarfamiliar

7. The workspace

The folder ships already set up. Nothing copies a template into a new project. The workspace, including .familiar-project, ships filled in as far as it can be without project facts. On its first real run, project-status → Check-in writes the project’s own facts into the remaining stub files (§4.1, §12).

familiar-workspace/
├── .familiar-project                   ships with created: not-yet-set; check-in stamps it on the first run
├── .familiar/
│   ├── routes.md, state-schema.md, extension-contract.md,
│   │   capabilities.json, extension-manifest.schema.json    protocol
│   ├── core/                           every core .md
│   ├── installed.json                  core version, capability states for each agent
│   ├── extensions/<id>/package/        each installed extension's package, if there are any
├── 1-Inputs/                           Sources/, Admin/, Templates/ (read-only)
├── 2-Drafts/                           generated outputs plus _draft-index.md
├── 3-Knowledge/                        index with review dates, knowledge pages
├── 4-Trackers/                         tasks.md, timeline.md, meetings.md
└── 5-System/                           config, context, Memory/, Decisions/, Handoffs/, preferences

file-handling.md sets what each folder owns:

  • 1-Inputs/ is source material, and it is read-only.
  • 3-Knowledge/ holds the knowledge built from those sources.
  • 2-Drafts/ holds outputs that wait for review.
  • 4-Trackers/ and 5-System/ hold the project state.

A project can rename the workspace folder. The agent finds it from the marker and never assumes it from the folder name. A project cannot quietly change what these folders mean.

Every folder ships an _about.md that says what the folder owns. An agent that lands in the folder without the rules loaded can still understand the layout.