bvandeusenandClaude Opus 5.5
c5eeec471f
CI & Build / Python lint (push) Successful in 3s
CI & Build / Plugin hooks (push) Successful in 14s
CI & Build / TypeScript typecheck (push) Successful in 53s
CI & Build / integration (push) Successful in 1m2s
CI & Build / Python tests (push) Failing after 1m26s
CI & Build / Build & push image (push) Skipped
Step 3 of the Scribe -> Grimoire rename. - Plugin `grimoire` in marketplace `grimoire-plugin`, MCP server key `grimoire`, so tools reach a session as mcp__plugin_grimoire_grimoire__*. - hooks/scribe_* -> hooks/grimoire_*, their shell functions and the TMPDIR ledgers with them; SCRIBE_URL / SCRIBE_TOKEN / SCRIBE_HOOK_DIR / SCRIBE_LEDGER_DIRS -> GRIMOIRE_*; the project marker is `.grimoire`. - skills/using-scribe -> using-grimoire, /grimoire:sync, stored processes arrive as grimoire-proc-<slug>; moment_actions names them the same way. - Migration 0124 rewrites stored skill names (rule_moments, rule_moment_judgments, moment_mappings) from scribe:/scribe-proc- to grimoire:/grimoire-proc-, so a rule mounted on a skill keeps firing. - Settings' install commands and MCP-only defaults, the docs and the tests follow. - scripts/check_plugin.py drops the smoke event for a report-check hook that has no file in plugin/hooks. Kept on purpose: the secret-sealing label, and the names that let backups written as Scribe restore and be counted. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
42 lines
2.0 KiB
Markdown
42 lines
2.0 KiB
Markdown
# Projects: binding a directory, and starting one
|
|
|
|
Part of the using-grimoire skill. Read it when a working directory maps to no
|
|
project, or when a new project is about to be created.
|
|
|
|
## Binding a directory to a project
|
|
|
|
**A directory does not have to be a git repo to have a project.** A repo is
|
|
bound by its remote (`list_repo_bindings` shows the bindings). Anything else —
|
|
a notes folder, a server's config directory, a scratch directory — is bound by
|
|
a `.grimoire` file naming the project:
|
|
|
|
{"instance": "https://grimoire.example.com", "project_id": 2, "project": "Homelab"}
|
|
|
|
`instance` is what makes the id trustworthy. An id means nothing on its own —
|
|
it is a different project on every Grimoire — so a marker that has travelled to
|
|
another instance is ignored rather than followed to the wrong project. A bare
|
|
`2` also works when writing the file by hand. When work plainly belongs to a
|
|
project and the directory names none, offer to write the marker;
|
|
`list_projects` has the id.
|
|
|
|
## Starting a project: decide what it inherits
|
|
|
|
A project's inheritance is a **decision, not a default**. Before
|
|
`create_project`, ask the operator the two inception questions and pass the
|
|
answers — never create a project bare by default:
|
|
|
|
- which **design system** its UI is built from (`list_design_systems`; or
|
|
none) → `design_system_id=<id | -1>`
|
|
- whether to **seed the standard starter Systems** so records can be tagged
|
|
from day one → `seed_systems=true|false`
|
|
|
|
Rules are not an inception question: a global rule already applies to every
|
|
project, and a project's own rules are written on it as they come up.
|
|
|
|
If `enter_project` returns an `inception` key, the project was never decided
|
|
(it inherits its defaults silently): raise that ask once, with the defaults it
|
|
carries, then `decide_project_inception(project_id, …)`. Existing projects
|
|
were stamped "legacy" and do not ask; any project can be re-decided. The
|
|
design-system and Systems tools still work one at a time — inception is the
|
|
moment they are decided together, and the record of why.
|