@lumerahq/cli 0.33.1 → 0.33.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lumerahq/cli",
-  "version": "0.33.1",
+  "version": "0.33.2",
   "description": "CLI for building and deploying Lumera apps",
   "type": "module",
   "engines": {

package/templates/default/AGENTS.md

@@ -1,56 +1,38 @@
 # {{projectTitle}}
 
-> Status: new project — nothing built yet.
-
-<!--
-AGENT CONTRACT — keep this file true.
-This is the project's durable memory, shared by every coding agent that works
-here. It records what cannot be re-derived from the code: why things are the
-way they are, what the business needs, what must not break.
-- Update it in the same turn as the change that makes it stale.
-- Small focused edits; delete stale lines rather than appending duplicates.
-- Leave a section empty rather than padding it.
-- Keep this file concise and always under 100 KB. Before an update would cross
-  that limit—or if the file is already over it—compact it in the same turn by
-  removing stale, superseded, duplicated, transient, and re-derivable detail
-  while preserving user-written notes.
-- Do NOT put here: platform documentation (skills and prompts carry that),
-  code inventories, secrets/credentials, or transient chat summaries.
--->
-
 ## What this is
 
-One paragraph: the problem this solves, for whom, and its current shape
+One short paragraph: the problem this solves, for whom, and its current shape
 (app / automation / agent / one-off analysis). Update when scope changes.
 
-## Business context
-
-- Who uses it, when, and for what workflow (roles, cadence — e.g. month-end)
-- Domain terms with tenant-specific meaning
-- Source-of-truth data and how it arrives (uploads, mailbox, webhooks, integrations)
-
-## Data
-
-- What each collection represents; non-obvious field/status semantics
-- Identifiers that map to external systems, and their formats
-
-## Decisions
-
-- YYYY-MM-DD — decision — why.
-
 ## Working agreements
 
-- User preferences: review gates, deploy expectations, formatting
-
-## Correctness
-
-- What "correct" means here: validations, reconciliations, tolerances, approvals
-- Known edge cases; behavior when required data is missing
-
-## Gotchas
-
-- Things that look wrong but are intentional; workarounds and why
-
-## Follow-ups
-
-- [ ] Open questions and deferred work
+Keep critical safety rules and user preferences that apply to every task here.
+
+## Managing memory
+
+- Keep this file short: ideally a few KB, always under 10 KB. Put detailed
+  knowledge in `memories/<topic>.md` and link it from the index below.
+- Save information that helps future agents: useful context, user preferences,
+  important decisions and their reasons, proven approaches, and lessons from
+  mistakes. Prefer knowledge that saves the user from repeating instructions or
+  future agents from rediscovering hard-won solutions. If there is nothing worth
+  remembering, do not update memory.
+- Distill what matters, not everything that happened. Keep routine progress and
+  temporary task state in the conversation.
+- Include useful paths, commands, and verification steps when they make a lesson
+  easier to reuse. For recurring problems, capture the symptom, cause, and proven
+  fix. Be honest about uncertainty. Do not turn a one-off request into a standing
+  rule. Check changeable facts against their source.
+- Read only relevant topics when needed; search if necessary. Do not load every
+  topic or use automatic file imports.
+- Organize by topic, not turn or date. Update existing notes, merge duplicates,
+  and remove outdated material. Keep memory files in version control and check
+  this file's size and links after changes.
+- Keep secrets out of memory. Link to source documents rather than copying them.
+  Data the app needs belongs in collections or app configuration.
+
+## Memory index
+
+Add one relative Markdown link with a one-line description per topic after
+creating the file. No topics recorded yet.