The vocabulary, defined once, properly.

A persistent, queryable store of what customers actually asked for (tickets, calls, Slack threads, notes) plus the team's recorded decisions, structured so a coding agent can ground its work in it.

Your agent already knows your code; product memory gives it your customers. Scriptonia defined and builds this category.

The per-project instance of agent product memory: all signal, contexts, rules, and plans for one product, kept isolated from every other project.

In Scriptonia, each repo gets its own brain at ~/.scriptonia/projects/<name>/, created by `scriptonia init`.

Raw, unedited evidence of what users want or struggle with: support tickets, sales-call transcripts, Slack messages, community posts, founder notes.

Signal is ingested verbatim and never summarized away; every later claim keeps a pointer back to its source.

A 0–10 score on a synthesized context reflecting how much independent, recent, high-intent signal supports it.

Three customers in one week beats one comment from last quarter.

A cluster of related signal synthesized into one structured, versioned document: summary, type, segment, cited sources, and any contradictions with recorded decisions.

A one-page markdown spec a coding agent can execute without follow-up questions: goal, cited evidence, constraints, non-goals, acceptance criteria, file-level steps, and a test plan, with machine-readable frontmatter.

Generated by `scriptonia plan "<issue>"` in about 15 seconds.

The PLAN.md section that names the adjacent features an agent must NOT build, converting scope from a vibe into an instruction.

The primary defense against agent over-building.

A blocking marker (⚠ UNRESOLVED) placed on any plan constraint that conflicts with a decision the team already recorded; the agent is instructed to stop until a human approves the override.

Approval is one comment; the plan regenerates with the gate marked RESOLVED and the sign-off recorded.

The recorded set of choices a team has made, including what they chose not to build and why; new plans are automatically checked against it.

This is the data that makes contradiction gates possible, and it only accrues through use.

Context packaged in a form an agent can act on directly (a plan with steps, criteria, and fences) rather than prose a human must re-type into a prompt.

A builder whose default engineering capacity is coding agents (Claude Code, Codex, Cursor, OpenClaw) rather than a hired team, making planning quality the main constraint on output.

The four-step working loop: add customer signal → generate a grounded plan → an agent executes it into a pull request → human comments regenerate the plan.

In Scriptonia: `add` → `plan` → your agent → `comment`.

The instruction file coding agents read before acting in a repo; Scriptonia writes its contract there so agents plan before building, respect non-goals, and stop on unresolved gates.