The Grimoire of Software Magic Words: Operative Vocabulary, Prompt-Spells, and Stacked Workflows

Original Corben Sorenson paper published as part of The ASI Stack source and lineage library.

← Corben Papers and Architecture Sources

ImportantOriginal paper, not rewritten book prose

This page publishes Corben Sorenson’s original source manuscript so readers can inspect the ideas that preceded or informed the living book. The text may contain historical terminology, claims, confidence, citations, or implementation status that the book later narrows, revises, tests, or rejects. Publication here establishes provenance and access—not correctness, novelty, replication, or support-state promotion.

Publication and provenance

Field	Record
Source ID	software_magic_grimoire
Source class	author paper
Library class	technical_specification
Manuscript date	Date not normalized
Inventory updated	Not separately recorded
Exact published-source SHA-256	bd841654248c8707cae8048ac8e4c12dd76fcd91775b7bd746048ba4eaead959
Exact published-source bytes	407,939
Exact source text	Download/view the tracked Markdown source
Book’s source note	Read the bounded mining note
Authorship and collaborator credits	Preserved from the exact original manuscript; this library wrapper does not replace or simplify them.
Rights	No new license grant. Corben Sorenson’s rights are reserved; collaborator, quotation, source-title, and third-party rights remain with their holders.

Current publication boundary. Archived author paper; its claims retain the status and limits stated in the paper and do not inherit the living book’s current evidence state.

HTML presentation note. The HTML page normalizes line endings and trailing whitespace, preserves explicit Markdown hard breaks, and demotes manuscript headings beneath the page title. The digest above applies to the linked exact source text, not to this presentation wrapper.

Where this paper enters the living book

Human Intent as a Formal Input, Command Contracts: From Intent to Executable Work, Planning as a Control Layer: DAGs and Intelligence Arbitrage, Labor OS and Typed Jobs, Runtime Adapters, Tool Permissions, and Human Approval

---

Original manuscript

full

The Grimoire of Software Magic Words An Overcomplete Field Guide to Operative Vocabulary, Prompt-Spells, and Numeric Spellcraft in Software and Hardware-through-Software Including a canonical sigil index, Gödel-style spell numbering, and a speculative coil geometry for promptcraft

Every software system is a ritual of names. The names that merely describe are ordinary. The names that constrain, invoke, transform, verify, or guard are magic. March 2026 · Public Release v1.0

Corben Sorenson ________________

I. On the Nature of the Software Magic Word This grimoire begins from a simple practical claim: in software engineering, some words do more work than others. A normal word points at a thing. A software magic word compresses a mechanism, a set of invariants, a failure surface, and an expected response. When an engineer says schema, quorum, interface, idempotent, rollback, zero-copy, or least privilege, the room does not merely receive vocabulary. It receives a compact operational model. That is why such words feel spell-like to practitioners. They are small verbal surfaces standing atop large hidden structures. They change what a reviewer looks for, what a compiler is allowed to reject, what a runtime must preserve, what a deployment pipeline may permit, and what an AI assistant should produce next. In that precise sense, software magic is not mystical. It is compressed coordination. Three ingredients give these words their force. First is semantic density: the token points into a dense conceptual network rather than a single flat meaning. Second is operational addressability: some actor can do something concrete because the word was uttered. Third is placement: the same token behaves differently in a prompt, a type signature, a migration file, a design memo, a runbook, a kernel comment, or a profiler note. Three Sources of Force • Semantic density - A magical word is concept-heavy. It carries assumptions about legality, timing, ownership, shape, authority, or outcome that would otherwise take sentences to unpack. • Operational addressability - A magical word matters because some person or system can respond to it. The word points not only to meaning but to action: reject, retry, cache, isolate, parallelize, encrypt, deploy, or verify. • Positional effect - Words gain or lose force depending on where they appear and what surrounds them. Context in software is not decorative; it is part of the spell. Software is unusually fertile ground for this phenomenon because computing is built from named abstractions that must coordinate across minds and machines. The distance between naming and consequence is short. A word in a config file can redirect traffic. A word in a type system can forbid an entire class of bugs. A word in a security policy can close an attack path. A word in a prompt can widen or sharply narrow the space of outputs an AI model is likely to produce. The metaphor is useful because it reminds us that language in engineering is operative. A design review is not only descriptive. It is a site where words allocate responsibility, mark hazards, define seams, and bind future work. Likewise, a prompt is not just a request for prose. It is a temporary control surface for a reasoning system. Once that is seen clearly, the move from ‘prompting’ to ‘spellcraft’ stops being cute and starts being practical. For numeric spellcraft, the true primitive is often not the surface spelling alone but the word-sense. Atomic in a database discussion is not identical to atomic in a CPU discussion. Model in data modeling is not the same as model in machine learning. State in a UI reducer is not the same as state in distributed consensus. The sigils later in this volume therefore name entries, not merely strings. Why the Metaphor Earns Its Keep Calling these words magical does two useful things. First, it teaches respect for arrangement. A pile of powerful terms does not make a strong spell; the order and relationship among them matters. Second, it foregrounds the shadow attached to every strong word. Cache implies staleness. Concurrency implies races. Generality implies abstraction cost. Automation implies brittle assumptions. The grimoire is interested in both the power and the price. Five Laws of the Software Magic Word • Compression - A magical software word packs far more concept than its length would suggest. Good engineering vocabulary is a compression scheme for shared judgment. • Placement - The effect of a word depends on where it is uttered: prompt, code, contract, config, runtime, incident report, benchmark, or review note. • Adjacency - Words amplify or constrain one another. Interface plus stable plus public implies caution. Temporary plus migration plus backfill implies staging and rollback. • Invocation surface - Words matter because some actor responds to them: a human teammate, a compiler, an interpreter, a scheduler, a pipeline, a model, or a machine. • Shadow - Every strong magic word has a failure shadow. Race shadows concurrency. Leak shadows allocation. Drift shadows state. Exploit shadows exposure. A good spell names the light and keeps an eye on the dark. Houses and Sigil Ranges The sigil numbers below define the canonical ranges used later in the lexicon. They are suitable as token ids in a stable spell vocabulary. The ranges are intentionally broad enough that a spell can move from architecture to runtime to testing to deployment without leaving the numbered field. • 0001-0112 - Architecture, Abstraction, and Design (112 entries) • 0113-0249 - Language, Semantics, and Formal Shape (137 entries) • 0250-0371 - Data, State, and Representation (122 entries) • 0372-0511 - Transformation, Algorithms, and Working Verbs (140 entries) • 0512-0608 - Control Flow, Coordination, and Temporal Logic (97 entries) • 0609-0684 - Runtime, Memory, and Execution (76 entries) • 0685-0770 - Systems Programming and Operating-System Words (86 entries) • 0771-0886 - Networking and Distributed Systems (116 entries) • 0887-0968 - Databases, Persistence, and Time-Binding Words (82 entries) • 0969-1063 - Security, Trust, and Warding Words (95 entries) • 1064-1139 - Build, Tooling, Versioning, and Release (76 entries) • 1140-1210 - Testing, Verification, and Observability (71 entries) • 1211-1290 - Hardware, Embedded, and Performance-Near Words (80 entries) • 1291-1350 - Interface, UX, and Human-Facing Words (60 entries) • 1351-1420 - Promptcraft, AI-Oriented Engineering, and Spell Structure (70 entries) • 1421-1512 - Guarantee Words, Quality Attributes, and Behavioral Adjectives (92 entries) • 1513-1582 - Failure Words, Pathologies, and Counter-Spells (70 entries) • 1583-1645 - Compound Forms, Prefixes, Suffixes, and Naming Runes (63 entries) II. What a Spell Is A spell, as the term is used here, is a deliberately shaped instruction artifact. It need not be mystical and it need not be verbose. It only needs to be arranged so that an invoked actor - human or machine - can transform a bounded context into a bounded software result. A spell is successful when it reduces ambiguity at the exact points where ambiguity would otherwise generate the wrong work. A wish says, ‘make this faster.’ A specification says, ‘reduce p95 latency below 80 ms without changing the external API.’ A program embodies a complete executable procedure. A spell sits in the middle. It is more concrete than a wish, more situated than a pure specification, and more portable than a full implementation. It is the layer where modern software work is often negotiated. This is especially true in AI-assisted engineering. We ask models to review diffs, draft migrations, explain stack traces, write tests, propose API shapes, summarize incident data, or generate bounded patches. In every case the model performs better when the spell explicitly names the artifact, the objective, the constraints, the expected output shape, and the truth conditions under which the result will later be judged. A useful canonical definition is: Spell S = (Role, Objective, Context, Constraints, Procedure, Output Contract, Verification, Failure Behavior). A tiny spell may compress some limbs into short phrases. A risky spell should usually make each limb explicit. The Eight Limbs of a Spell • Role - What kind of actor is being invoked? Senior backend engineer, migration planner, security reviewer, incident analyst, compiler tutor, test engineer, or architecture critic. • Objective - What outcome matters most? Not general helpfulness, but the primary transformation: preserve behavior, cut latency, diagnose cause, design a stable API, migrate safely, or generate tests. • Context - What local world is already true? Versions, architecture, runtime environment, current symptoms, existing files, performance characteristics, and constraints inherited from the surrounding system. • Constraints - What may not break? Public interfaces, dependency policy, latency budgets, security boundaries, rollout windows, file scope, team conventions, or compliance rules. • Procedure - How should the work proceed? Ask for staged analysis, invariants first, edge cases, tradeoffs, minimal patching, test strategy, rollback, or explicit assumptions. • Output contract - What shape must the answer take? Diff, code block, test file, incident timeline, RFC outline, migration plan, checklist, table, or short recommendation memo. • Verification - How will truth be checked? Unit tests, invariants, sample inputs, reproducible commands, schema checks, performance measurements, or security review criteria. • Failure behavior - What should happen if context is missing or contradictory? Ask for assumptions, refuse unsafe changes, propose the smallest safe next step, or return a questions-first response. These limbs can be collapsed for tiny tasks, but every omitted limb tends to reappear somewhere as risk. If Role is missing, the assistant may reason from the wrong frame. If Constraints are missing, it may optimize the wrong variable. If Verification is missing, it may produce output that is fluent but ungrounded. If Failure Behavior is missing, it may invent facts rather than surface uncertainty. Cast Levels and Minimum Adequate Ritual The eight-limb form is the complete anatomy of a spell, not a demand that every request be ceremonial. Public release version 3 therefore distinguishes three cast levels. The theory stays whole; the daily burden scales with risk. • Quick cast - ROLE | OBJECTIVE | CONTEXT | VERIFY. Use this for explanation, review, drafting, and low-risk bounded tasks where the artifact is small and the blast radius is local. • Working cast - ROLE | OBJECTIVE | CONTEXT | CONSTRAINTS | OUTPUT | VERIFY. This is the daily engineering form. It is usually enough for code edits, test writing, API sketches, benchmarking requests, and design comparison. • Full ritual - ROLE | OBJECTIVE | CONTEXT | CONSTRAINTS | PROCEDURE | OUTPUT | VERIFY | FAILURE. Use this when the work can damage production reality, hide uncertainty, or automate across multiple steps: migrations, refactors, incidents, security-sensitive work, or agentic pipelines. A good rule is simple: the more a spell can change durable state, public behavior, or team time, the more limbs it should carry. Minimal form is a convenience. Full form is a safety device. Canonical Spell Skeleton ROLE: [what actor or expertise is being invoked]

OBJECTIVE: [what outcome matters most]

CONTEXT: [local facts, environment, versions, architecture, constraints already true]

CONSTRAINTS: [non-negotiables, things that must not break, banned dependencies, limits]

PROCEDURE: [how the work should proceed; ask for invariants, edge cases, tradeoffs, or staged reasoning]

OUTPUT CONTRACT: [required output shape: diff, code, table, checklist, RFC outline, test plan, etc.]

VERIFICATION: [how to check truth or correctness]

FAILURE BEHAVIOR: [what to do if information is missing, ambiguous, or conflicting] From Wish to Spell The difference between a weak request and a strong spell is not theatricality. It is inspectability. A strong spell can be critiqued, versioned, canonicalized, debugged, and partly automated. A weak wish usually cannot. In practice, the shift often looks like moving from vague adjectives to concrete invariants and output shapes. WEAK: Optimize this endpoint and make the code cleaner.

STRONGER: Reduce p95 latency on GET /accounts by at least 20 percent without changing the JSON schema or adding third-party dependencies. Return the likely bottlenecks, the minimal patch, and the tests needed to prove behavior is preserved. III. How to Craft Software Spells To craft a good software spell, begin by reducing ambiguity rather than by increasing drama. The best spells do not rely on ornate wording. They rely on bounded context, visible constraints, explicit artifacts, and a clear test for success. Good promptcraft is therefore closer to writing an excellent engineering ticket or review request than to improvising clever prose. A useful distinction is between exploration spells and execution spells. Exploration spells are for mapping the space: identify causes, outline options, compare designs, surface tradeoffs, list invariants, or ask questions. Execution spells are for producing a bounded artifact: write the patch, generate the migration, draft the tests, or emit the checklist. Confusing the two is a common source of disappointing results. A Practical Spellcraft Workflow • Name the artifact - Say exactly what is being acted on: file, module, function, endpoint, query, table, migration, service, build step, alert, or design document. • State the invariant - Name what must stay true while the change happens: public behavior, schema shape, latency ceiling, auth boundary, ordering guarantee, or backward compatibility. • State the desired change - Name the transformation itself, not just the dissatisfaction: deduplicate, diagnose, refactor, batch, paginate, normalize, backfill, instrument, rollback, or harden. • Bound the search space - Call out dependency bans, time limits, file limits, version constraints, deployment rules, and other non-negotiables so the model does not solve the problem by stepping outside the acceptable world. • Demand an output shape - Ask for a diff, plan, table, checklist, RFC outline, set of tests, or incident timeline. Shape turns free response into deliverable work. • Force verification - Require tests, sample inputs, performance checks, risk notes, or commands to reproduce. Truth conditions are part of the spell, not an afterthought. • Decide failure behavior - Tell the model what to do when information is missing. Safe uncertainty beats confident invention every time. Common Prompt Pathologies • Vague target - Words like better, cleaner, simpler, or more scalable do not specify what metric or invariant matters. • Hidden constraints - If API stability, compliance, or deployment rules are important but unstated, the model may optimize for the wrong world. • Missing artifact boundary - Without a stated file or subsystem boundary, the solution may sprawl across the codebase. • No output contract - A response can sound helpful while remaining unusable. Specify the artifact to receive. • No truth test - Without verification, the spell rewards plausibility rather than correctness. • No fallback behavior - When uncertainty is not handled explicitly, the model is tempted to fill gaps with invented specifics. Most bad prompts are not too short or too long. They are under-structured. The cure is not to add adjectives. The cure is to name the right nouns, the right invariants, and the right acceptance checks. Practical Principles • Separate facts from wishes - Facts belong in Context and Constraints. Desired transformations belong in Objective. Mixing them creates unstable instructions. • Ask for intermediate structure - For nontrivial tasks, request assumptions, invariants, edge cases, or a short risk analysis before the final artifact. • Prefer bounded patches - A small correct change with tests is usually more valuable than a sweeping rewrite with unclear blast radius. • Keep verification close to the request - Do not rely on the model to infer what proof is expected. Name the tests or checks explicitly. • Use pressure only where it matters - A good spell is not maximalist. It is selective. Tighten the high-risk dimensions; leave harmless details loose. A Tiny Repair Example WEAK: Design an API for billing.

REPAIRED: Design a REST API for recurring subscription billing. Return the core resources, endpoints, idempotency strategy for payment retries, error model, and the migration risks if we later add invoice preview and proration. IV. Numeric Spellcraft: Sigils, Canonicalization, and Gödel Numbers Reducing a spell to a number is completely workable, but only after the spell has been canonicalized. This condition matters. Gödel encoding does not rescue ambiguity; it faithfully encodes whatever ordered token stream you give it. The difficult part is therefore not exponentiation but normalization. A practical canonical vocabulary needs at least four token families. First are structural tokens such as ROLE, OBJECTIVE, CONTEXT, and VERIFY. Second are lexicon tokens drawn from the houses of this grimoire: interface, idempotent, migrate, shard, rollback, and so on, resolved at the level of word-sense. Third are literals or out-of-vocabulary items such as file names, version numbers, endpoint paths, and schema names. Fourth are relation tokens that preserve order, separators, and scope where those affect interpretation. Canonicalization Pipeline • Normalize text - Regularize whitespace, case policy, punctuation policy, and section labels so superficial formatting differences do not produce different signatures. • Split by spell limbs - Parse the artifact into named fields such as Role, Objective, Context, and so on. Field order becomes part of the canonical form. • Resolve word-senses - Map lexicon terms to their house-specific sigils where possible. Atomic{database} and atomic{cpu} must remain distinguishable if the ontology requires it. • Encode literals - Preserve concrete names, paths, versions, and other local tokens through a consistent literal scheme so the spell remains reconstructible. • Serialize structure - Emit the ordered token stream, including structural delimiters or field markers needed to recover the original normalized arrangement. • Assign token ids - Map each structural token, sigil token, and literal token to its canonical integer id. • Construct the number - Apply the prime-exponent scheme or an equivalent injective encoding to the ordered id sequence. This means the Gödel number is not a universal fingerprint of abstract meaning. It is a fingerprint of one agreed canonical representation. Two prompts that feel semantically similar but canonicalize differently will receive different numbers. That is acceptable. Engineering usually needs disciplined sameness, not metaphysical sameness. Once a spell has been normalized into a token sequence T = (t1, t2, …, tn), a Gödel-style spell number can be defined as G(T) = product over i from 1 to n of p_i^(t_i + 1), where p_i is the i-th prime. The +1 prevents zero exponents and keeps every position visible in the factorization. The fully expanded decimal integer becomes enormous almost immediately. That is normal behavior, not a defect. In practice the useful forms are the canonical token stream, the sparse prime-exponent vector, and a short operational digest of the canonical form. The digest is the pocket sigil. The prime-exponent form is the rigorous underlying encoding. What the Number Buys You • Stable reference - A spell can be named, cached, versioned, and discussed without relying on its full prose every time. • Diffability - Small changes in structure or sigils become visible as token edits or exponent changes rather than vague prose drift. • Evaluation hooks - Prompts used in tooling or experiments can be logged, compared, clustered, and replayed against model changes. • Geometric rendering - The same canonical structure can feed later visualizations such as clause circles, antinode diagrams, or prompt families. Formal Sigils, Working Seals, and Human Titles For public use it helps to separate three layers that are easy to confuse. A human title is the browsable name of the spell: Safe refactor of account serializer. A working seal is the short practical handle a team can carry in commits, notebooks, dashboards, or a prompt registry. A formal sigil is the exact canonical token stream together with its injective numeric encoding. Humans should usually exchange titles and seals. Tooling should preserve formal sigils. The point of the mathematics is not to force engineers to hand-compute astronomical integers; it is to make prompt identity stable enough for versioning, replay, clustering, and audit. • Human title - memorable, descriptive, and optimized for browsing. • Working seal - short, portable, and easy to paste into issue trackers or commit messages; for example spell://safe-refactor/9H4X2Q. • Formal sigil - canonical token stream plus Gödel-style encoding; exact, reproducible, and meant for tools rather than conversation. Adoption Ladder • Manual practice - use the spell skeleton and a good title. • Team practice - add a working seal and keep canonical prompt text under version control. • Tooling practice - store the formal sigil, render the coil, and log evaluation results against model and prompt versions. The deep structure can be exact without demanding exactness from the human every time. That is the right relationship between theory and practice. Toy Example Toy vocabulary: ROLE=1, OBJECTIVE=2, CONTEXT=3, CONSTRAINTS=4, OUTPUT=5, VERIFY=6, python=7, refactor=8, test=9, diff=10. Canonical token stream: [ROLE, python, OBJECTIVE, refactor, CONTEXT, CONSTRAINTS, OUTPUT, diff, VERIFY, test]. Numeric stream: [1, 7, 2, 8, 3, 4, 5, 10, 6, 9]. Godel-style signature: 2^(1+1) * 3^(7+1) * 5^(2+1) * 7^(8+1) * 11^(3+1) * 13^(4+1) * 17^(5+1) * 19^(10+1) * 23^(6+1) * 29^(9+1). In tooling, this prime-exponent form is usually stored symbolically rather than expanded into decimal. Practical note: if you want one field-portable identifier for a spell, keep both forms: the canonical token stream for reconstruction and a short digest for transport; treat the Gödel factorization as the lossless underlying signature. V. Coil Geometry for Spells There is also a geometric way to imagine spells. Once a spell has named clauses, we can stop treating it as a flat line of text and instead treat it as a circuit of commitments. The point of the geometry is not mystique for its own sake. It is inspection. Geometry makes it easier to see missing sectors, overloaded crossings, and contradictions that disappear in linear prose. Your Temporal Coil Networks idea fits here as a provocative higher-order analogue. Prime-sized circles, skip patterns, and antinode intersections offer a disciplined language for long-range dependencies among spell components. The grimoire does not depend on that architecture being the final neural answer. It is enough that the coil gives us a strong visual grammar for prompt structure and a way to talk about clause interaction with more precision than ‘this prompt feels better’. Clause Circle Minimal clause circle with p = 7: 0 Role 1 Objective 2 Context 3 Constraints 4 Procedure 5 Output Contract 6 Verification With p = 7 the spell is compact and easy to reason about. With p = 11 or p = 13, separate sectors can be added for Failure Behavior, Assumptions, Non-goals, Rollback, Evidence, or Test Strategy. Prime sizes are attractive because they reduce trivial repetition patterns and make skip-based traversals less redundant. Antinodes and Cross-Checks • Objective x Verification - Can the claimed success condition actually be checked, measured, or falsified? • Context x Constraints - Does the local world agree with the non-negotiables, or is the spell already self-contradictory? • Procedure x Output - Will the requested method actually produce the requested artifact, or are we asking for the wrong work product? • Constraints x Failure Behavior - When uncertainty appears, does the spell degrade safely, or does it invite fabricated certainty? • Role x Output - Is the invoked expertise aligned with the artifact requested, or has the spell summoned the wrong kind of helper? These crossings are the semantic antinodes of the spell. High-quality prompts tend to have meaningful crossings that reinforce one another. Weak prompts often show dead sectors, decorative clauses, or contradictions that only become visible when distant parts of the request are made to touch.

Figure 1. An inspection coil for a seven-limb spell. The order around the circle is chosen for visual inspection rather than canonical token order; the colored chords mark high-value clause interactions and the red antinodes show where contradictions or missing proofs become easiest to see. What a Broken Coil Looks Like • Missing sector - A clause is absent entirely. The prompt wants a result but never states the invariant or the truth condition. • False bridge - Two clauses touch rhetorically but not operationally. The procedure sounds impressive but cannot yield the promised output. • Contradiction chord - One part of the spell silently cancels another, such as demanding a large refactor while forbidding all touched files except one. • Decorative clause - A sentence adds mood or style but no operational narrowing. In canonical terms it contributes little but noise. • Unchecked objective - The goal is stated but no measurement or test is attached, so the spell cannot close the loop on truth. If this view proves useful, one can imagine a future spellbook tool that takes a canonical prompt, renders a p = 7 or p = 11 clause circle, highlights the strong and weak antinodes, and emits both a compact digest and a symbolic Gödel factorization. The geometry would then be more than metaphor. It would become a debugging surface for prompt design. How to Use Coil Geometry Without Overengineering It • Use it manually as a review lens when a prompt feels wrong but the defect is hard to name. Missing sectors, contradiction chords, and empty verification crossings usually reveal the problem quickly. • Use it at team scale to compare prompt families. Two spells may look similar in prose while differing sharply in where they place proof, rollback, or uncertainty handling. • Use it in tooling when you want rendered diagrams, clustering, or prompt linting. The geometry earns its keep when it becomes inspectable, not when it becomes ceremonial. No one should have to hand-draw a coil before asking for a unit test. The geometry is a second-order instrument: a way to make clause interaction visible when visibility matters. VI. Example Spells for AI-Assisted Software Engineering The example spells that follow are meant to be adapted rather than memorized. Their job is to show how software requests become more reliable when they explicitly name role, artifact, invariants, output shape, and truth conditions. Each spell can later be compressed, canonicalized, or translated into sigil form, but it is helpful to first see the structure in full prose. How to Read and Adapt These Spells • Keep the skeleton, swap the nouns - The field structure is often more important than the exact phrasing. Replace the local artifact names, versions, or risk notes while preserving the underlying limbs. • Change Objective before Procedure - If the spell feels wrong, fix the desired outcome first. Procedure should serve the objective, not substitute for it. • Tighten constraints as risk rises - Production changes, security-sensitive work, migrations, and public APIs deserve stronger non-negotiables than low-risk exploratory analysis. • Never drop verification on high-impact work - The more the answer can touch reality, the more the spell should demand explicit proof, tests, or checks. • Use failure behavior to control uncertainty - When context may be incomplete, say so and tell the system how to proceed safely rather than leaving it to guess. When a spell feels too long, cut decoration before you cut structure. Remove redundancy, grandiose framing, and harmless adjectives first. Keep the nouns, invariants, and verification clauses that make the request safe and testable. Spell of Safe Refactoring ROLE: Act as a senior Python engineer performing behavior-preserving refactoring.

OBJECTIVE: Refactor the supplied module to reduce duplication and improve readability without changing public behavior.

CONTEXT: Python 3.12. The module runs inside a web API process and is called on every request. Existing tests are incomplete. The function signatures are part of a stable public API.

CONSTRAINTS: Do not add third-party dependencies. Do not change public function names, parameter order, or return schema. Preserve current logging side effects unless they are obviously duplicated. Keep the patch bounded to the supplied file unless a test file is requested.

PROCEDURE: First identify the invariants that must remain true. Then list duplication or code-smell candidates. Propose the minimal refactor that removes the duplication. Explain tradeoffs briefly before showing code.

OUTPUT CONTRACT: Return: 1. a short summary, 2. the invariants, 3. a unified diff, 4. the revised code, 5. a targeted test plan.

VERIFICATION: Include edge cases for empty input, malformed input, Unicode content, and large input size. State why the refactor preserves behavior.

FAILURE BEHAVIOR: If behavior cannot be inferred from the provided code, say exactly what is ambiguous and proceed with the safest minimal change. Spell of Bug Diagnosis from Logs ROLE: Act as a production incident engineer diagnosing a backend failure.

OBJECTIVE: Determine the most likely root causes of the supplied error logs and propose the shortest safe path to confirmation and mitigation.

CONTEXT: The service is a stateless containerized API backed by PostgreSQL and Redis. Latency SLO is 250 ms p95. A recent deploy occurred within the last hour.

CONSTRAINTS: Do not assume facts not present in the logs. Separate confirmed observations from hypotheses. Prefer mitigations that are reversible and low-risk. Mention monitoring to watch during mitigation.

PROCEDURE: Extract the timeline, cluster repeated errors, identify likely failure domain, and rank hypotheses. For each hypothesis, give one confirming check and one mitigating action. Call out whether the problem looks like config, code, dependency, infrastructure, or data.

OUTPUT CONTRACT: Return: 1. confirmed observations, 2. ranked hypotheses, 3. immediate mitigation options, 4. confirmation steps, 5. rollback criteria.

VERIFICATION: Tie every claim to a concrete log line or absence of an expected line.

FAILURE BEHAVIOR: If the logs are insufficient, say what additional evidence would most reduce uncertainty. Spell of API Design ROLE: Act as a backend architect designing a public JSON API.

OBJECTIVE: Design an API for the described resource model that is clean, versionable, secure, and observable.

CONTEXT: Clients include web, mobile, and internal automation. The system uses OAuth-based authorization and PostgreSQL storage. Backward compatibility matters because mobile clients update slowly.

CONSTRAINTS: Prefer boring, maintainable patterns over novelty. Include pagination, error schema, idempotency where appropriate, authorization notes, and migration considerations. Do not hand-wave failure modes.

PROCEDURE: Start from the resource model and operations. Then define endpoints, request and response schemas, error codes, pagination, filtering, authorization checks, and observability requirements.

OUTPUT CONTRACT: Return: 1. resource model, 2. endpoint table, 3. example requests and responses, 4. error format, 5. auth model, 6. migration and versioning notes.

VERIFICATION: Call out edge cases, race conditions, and compatibility risks.

FAILURE BEHAVIOR: If the resource model is underspecified, list the assumptions explicitly before designing. Spell of Migration Without Data Loss ROLE: Act as a database migration engineer.

OBJECTIVE: Plan a schema and data migration that preserves correctness, minimizes downtime, and has a clear rollback strategy.

CONTEXT: PostgreSQL production database, high write volume, zero-downtime preference, mixed old and new application versions during rollout.

CONSTRAINTS: Assume the table is large. Avoid long exclusive locks where possible. Preserve existing reads during rollout. Include backfill strategy, validation queries, and rollback conditions.

PROCEDURE: Describe the expand-and-contract sequence. Note schema changes, dual-write or compatibility windows, backfill steps, validation queries, cutover criteria, and cleanup.

OUTPUT CONTRACT: Return: 1. migration phases, 2. SQL or pseudo-SQL snippets, 3. application changes required, 4. validation checklist, 5. rollback plan.

VERIFICATION: State how to verify row counts, nullability, foreign-key integrity, and read/write correctness at each phase.

FAILURE BEHAVIOR: If downtime or lock risk cannot be avoided, say so explicitly and estimate where the risk concentrates. Spell of Test Generation ROLE: Act as a meticulous test engineer.

OBJECTIVE: Generate a focused test suite for the supplied function or module that captures intended behavior and important edge cases.

CONTEXT: The code may be partially undocumented. Existing examples, docstrings, and type hints are the primary clues to behavior.

CONSTRAINTS: Prefer high-signal tests over high-count tests. Group tests by behavior. Avoid mocking unless interaction boundaries require it. Call out assumptions whenever behavior is not explicit.

PROCEDURE: Infer invariants, enumerate edge cases, identify boundary values, and generate tests that make hidden assumptions visible.

OUTPUT CONTRACT: Return: 1. inferred behaviors, 2. missing-behavior ambiguities, 3. the test file, 4. a short rationale for each test group.

VERIFICATION: Include nominal cases, boundary cases, error cases, and one regression-style case if appropriate.

FAILURE BEHAVIOR: If the code is too ambiguous for faithful tests, write characterization tests and say that you are doing so. Spell of Performance Tuning ROLE: Act as a performance engineer.

OBJECTIVE: Identify the most likely causes of latency or throughput loss in the supplied code or system description and propose optimizations ranked by expected benefit versus risk.

CONTEXT: The service has a strict latency budget and runs on commodity cloud hardware. A profiler or benchmark may or may not be available.

CONSTRAINTS: Do not recommend micro-optimizations before addressing algorithmic or I/O-bound issues. Separate CPU, memory, allocation, database, and network effects. Mention measurement strategy.

PROCEDURE: First classify the probable bottleneck class. Then propose measurement steps. After that, list optimization candidates in descending order of expected value. Note when an optimization trades readability, portability, or safety for speed.

OUTPUT CONTRACT: Return: 1. bottleneck hypotheses, 2. what to measure, 3. optimization options ranked by expected payoff, 4. benchmark plan, 5. rollback criteria.

VERIFICATION: State how success will be measured and what regression risks need to be watched.

FAILURE BEHAVIOR: If evidence is insufficient, say what profile, trace, or benchmark data would most improve the recommendation. ________________

7. The Public Canon: Major Arcana and Proof by Difference The full lexicon is an exhaustive back-catalogue. Public use begins with a smaller canon: the words that repeatedly alter code review, architecture, incident response, migration planning, benchmarking, deployment, and AI-assisted engineering. The fifty entries below are not the only force-bearing runes. They are the ones most likely to change outcomes when named early and used precisely. These entries are deliberately richer than the compact master lexicon. Each gives a force description, a practical use, and a failure shadow. Read them as the major arcana of software spellcraft: not complete, but disproportionately world-running. The Fifty World-Running Words The list is arranged in five clusters so the reader can move from design seams to durable truth, from runtime pressure to proof surfaces, and finally to authority and named failure shadows. Boundaries, seams, and collaboration [0001] abstraction — A deliberate forgetting of detail so larger structure can be reasoned about without drowning in mechanism. Shadow: hiding the only failure that matters. [0002] adapter — A negotiated translator between unlike shapes. Use it when two systems must meet without infecting one another. Shadow: adapter jungles that preserve confusion rather than resolve it. [0006] API gateway — A threshold that centralizes entry, policy, and routing at the edge of a service world. Shadow: a convenience chokepoint that quietly becomes a monolith. [0012] boundary — The line that says where one responsibility ends and another begins. Shadow: porous edges that smear blame, ownership, and test scope. [0013] bounded context — A protection against semantic bleed: the same word may not mean the same thing in every subsystem. Shadow: false unification through shared names. [0030] coupling — The hidden tax paid when change in one place forces change elsewhere. Name it early if you want modularity to survive contact with reality. [0034] dependency inversion — Stable policy should not kneel before unstable detail. Shadow: concrete dependencies hard-wired into places that should remain portable. [0055] interface {Arch} — A disciplined seam that lets unlike bodies cooperate without swapping internal organs. Shadow: tight coupling and type bleed. [0347] schema {Data} — The declared shape of stored meaning. Shadow: drift, silent coercion, and backward-incompatible surprise. [1152] contract test — A promise checked at the seam between systems. Use it when mocks are too flattering and end-to-end tests are too blunt. State, durable truth, and reversibility [1172] invariant — A law that must remain true while the rest of the system is allowed to move. If you cannot say the invariant, you probably do not yet understand the change. [0926] migration — Stored reality changing shape without being lost. Good migrations are staged, inspectable, and reversible long enough to discover what the data actually contains. [0898] commit {DB} — The moment a proposed change becomes durable history. Shadow: writing too early, before the world is actually ready to carry the new truth. [0943] rollback {DB} — Permission to retreat toward a previously trusted state. A system without rollback mistakes hope for safety. [0805] eventual consistency — Agreement postponed rather than denied. Shadow: stale reads treated as if they were fresh truth. [0848] quorum — Not everyone must agree, but enough must. This word turns distributed action into a threshold question instead of a unanimous fantasy. [1461] idempotent — The word that makes retries survivable: same request, same lasting effect. Shadow: duplicate charges, duplicate emails, and fear of recovery. [1425] atomic — No halfway state is allowed to leak across the line. Use it when partial success would be indistinguishable from corruption. [1445] deterministic — Given the same inputs, the same result should return. This is the antidote to drift, heisenbugs, and unreviewable behavior. [1492] serializable {Qual} — Concurrency forced to behave as though transactions happened in one clean order. Expensive when overused, indispensable when history must remain sane. Runtime pressure, behavior, and operational physics [1481] pure — Same inputs, same output, no hidden state smuggled in from the side. Use it to shrink reasoning scope. [1462] immutable — Once written, this thing does not change in place. Immutability buys clarity, replayability, and safer sharing at the cost of update convenience. [0576] retry {Ctrl} — Failure does not necessarily end the ritual; policy may permit another attempt. Shadow: blind repetition against a broken precondition. [0598] timeout {Ctrl} — Waiting is not free and patience must have a boundary. A timeout is a contract with reality about how long uncertainty is allowed to persist. [0825] latency — The delay before useful work reaches the caller. Latency is what users feel even when throughput graphs look flattering. [1281] throughput — How much useful work the system can push through a narrow world in bounded time. Shadow: chasing bulk capacity while tail latency burns the user. [0778] backpressure — Resistance pushed upstream when demand outruns capacity. Without it, overload spreads faster than truth. [0615] cache {Run} — Keep likely things close so future cost falls. Shadow: stale truth delivered at machine speed. [0684] zero-copy {Run} — Data movement stripped down to the minimum number of duplications. Use it when the bottleneck is physical movement rather than arithmetic. [1472] memory-safe {Qual} — A promise that the system will not casually trespass across allocation boundaries. Shadow: leaks, corruption, and security bugs born from illegal touch. Observation, release, and proof surfaces [1180] observability — Enough internal evidence exists that you can infer what the system is doing from the outside. Not logs alone: legible state under pressure. [1202] telemetry — Measurements leaving the system in a form other systems can compare, store, and alert on. Shadow: metric exhaust without explanatory power. [1204] trace {Proof} — A preserved path through execution. Use it when the question is not only what failed, but where the causal thread first bent. [1146] benchmark — A performance claim forced to meet measurement. Benchmarks are where speed rhetoric either cashes out or dies. [1073] canary — A deliberately limited release whose job is to discover whether production reality agrees with the story told in staging. [1086] deploy — The crossing from forge to world. Many good ideas become bad facts only after they are actually shipped. [1088] diff {Forge} — A visible account of what changed between one state and another. Good diffs make review local; bad diffs turn truth into fog. [1186] property-based test — Instead of checking one remembered example, ask whether a law survives many generated cases. Use it when you care more about the invariant than the anecdote. [0974] attestation — A proof that a thing is what it claims to be or was produced the way it claims. It matters most when trust cannot be assumed. [1467] linearizable — Every operation behaves as though it took effect at one real instant visible to all observers. Use it rarely, but mean it fully. Authority, trust, and named shadows [1017] least privilege — Give only the authority required for the present act, no more. It is one of the simplest words for reducing future regret. [0978] authorization — After identity is known, what acts are permitted? Shadow: accidental omnipotence hidden behind a successful login. [0976] authenticate — Prove who is making the claim before deciding what the claimant may do. Shadow: trusting names that have not earned entrance. [1050] signature {Sec} — Identity or intent made checkable through cryptographic proof. Useful wherever trust must survive distance and replay. [1007] hash {Sec} — Arbitrary input reduced to a fixed fingerprint. Use it for identity, integrity, bucketing, and change detection; never mistake it for secrecy. [1028] policy — The declared rule by which a class of cases is decided. Good policy reduces arbitrary judgment; bad policy merely freezes confusion. [1561] race — An ordering curse: outcomes depend on timing you do not actually control. Name the race and the system becomes debuggable again. [1546] leak {Curse} — Something escapes the boundary that should have held it: memory, secrets, file descriptors, authority, abstraction, or time. [1567] schema drift — The stored world and the assumed world have silently stopped matching. This is how migrations keep hurting after everyone thinks they are done. [1564] retry storm — Recovery logic amplifying failure instead of containing it. Unguided retries can turn a partial outage into a self-made siege. Proof by Difference A public methodology earns trust when it shows not only the polished theory but the practical delta. The three cases below are archetypal rather than model-specific. Their job is to show how structure changes the probable quality of the answer. Case I. Refactor Without Breaking Behavior Weak request Clean up this Python module and make it nicer. Repaired spell ROLE: Act as a senior Python engineer performing behavior-preserving refactoring. OBJECTIVE: Remove duplication in the supplied module without changing public behavior. CONTEXT: The module is imported by two API handlers and one CLI entry point. Python 3.11. Existing tests cover only the happy path. CONSTRAINTS: Do not change public function names, parameter order, return types, or raised exception classes. Touch only this module and its tests. OUTPUT CONTRACT: Return a minimal patch plan, the proposed refactor, and tests that prove unchanged behavior. VERIFICATION: State the invariants first; then show before/after test cases for edge inputs. FAILURE BEHAVIOR: If the module boundary is too small for a safe refactor, say exactly what adjacent file must also move and why. Weak-cast answers tend to widen the blast radius: renamed public helpers, decorative rewrites, and claims of cleanliness without behavioral proof. The repaired spell forces the assistant to surface invariants, stay inside a bounded file set, and pay its debt in tests. Review becomes local because the spell demanded locality. Case II. Online Migration Without Data Loss Weak request Migrate users.birthdate from string to date. Repaired spell ROLE: Act as a migration planner for a production PostgreSQL system. OBJECTIVE: Move users.birthdate from VARCHAR to DATE without data loss and without breaking reads or writes during rollout. CONTEXT: The table is large, writes continue during business hours, and some existing rows contain invalid or partial dates. CONSTRAINTS: Use an expand-and-contract strategy. Preserve rollback until data quality is validated. Assume two application deploys are allowed. OUTPUT CONTRACT: Return phased SQL and application steps: schema expand, dual write, backfill, validation queries, read switch, cleanup, rollback plan. VERIFICATION: Include checks for invalid rows, null behavior, row-count parity, and post-cutover consistency. FAILURE BEHAVIOR: If the data quality problem is too large for a safe automatic cast, stop at the quarantine step and describe the manual decision boundary. Weak-cast answers often collapse directly to ALTER COLUMN … TYPE DATE and call the job done. The repaired spell produces a staged migration, names the dirty-data problem, preserves reversibility, and makes validation first-class. Instead of a single irreversible act, the result becomes a controlled campaign. Case III. Incident Diagnosis Without Fake Certainty Weak request Why are requests timing out? Repaired spell ROLE: Act as a production incident analyst. OBJECTIVE: Narrow the most likely causes of the timeout spike and say what evidence would distinguish them. CONTEXT: A web API talks to Redis and PostgreSQL. Latency increased in the last hour. No code deploy is known. Logs are partial. CONSTRAINTS: Do not claim a root cause that is not supported by the supplied evidence. Distinguish hypothesis from fact. OUTPUT CONTRACT: Return ranked hypotheses, evidence already present, missing evidence, and the next three commands or dashboards to inspect. VERIFICATION: Every factual claim must cite the observed symptom that supports it or else be labeled hypothesis. FAILURE BEHAVIOR: If the evidence is insufficient, say insufficient and identify the minimum additional signals needed to move from speculation to diagnosis. Weak-cast answers guess. Strong-cast answers separate observation from hypothesis, preserve uncertainty, and still move the operator forward. The repaired spell does not magically know the root cause; it prevents counterfeit knowing while still producing useful next steps. What the Delta Teaches • Good spellcraft does not guarantee a perfect answer; it reliably raises the floor by forcing the right nouns, invariants, and truth tests into the request. • The biggest gains usually come from three moves: narrowing the artifact boundary, naming the invariant, and specifying how correctness will be checked. • Failure behavior is not decorative. It is what prevents an assistant from converting missing context into counterfeit certainty. • A repaired spell is easier to review, version, compare, and automate because its obligations are explicit rather than implied. • The more expensive the real-world mistake, the more the spell should pay in verification and rollback language up front. This is the practical thesis of the whole grimoire. Spellcraft is not about sounding commanding, mystical, or verbose. It is about giving language enough structure that useful work can be distinguished from plausible theater. ________________

How to Read the Master Lexicon The master lexicon is overcomplete by design. It includes near-synonyms, neighboring senses, and families of compounds because software work is unusually sensitive to nuance. The public canon above gives the richer entry form. The master lexicon below compresses for breadth, stable numbering, and scanability. Each entry is a word-sense with a sigil number, a house label, and an operative gloss. Read the section in four ways: as a technical reference, as a vocabulary source for constructing better prompts, as a map of guarantee words and failure shadows, and as the numbered substrate from which canonical spell encodings can be built. When a compact gloss feels too small, treat the Public Canon as the expanded commentary layer for the most repeatedly useful runes. • Browse by house - When framing a task, move through the relevant domains: architecture, data, runtime, testing, security, deployment, or human interface. • Pair light with shadow - Strong guarantees become more useful when read beside their corresponding pathologies: consistency beside drift, concurrency beside race, allocation beside leak, exposure beside exploit. • Use sigils as stable handles - When canonicalizing a spell, treat the lexicon entries as reusable numbered components rather than as ornamental vocabulary. • Treat compounds as tuning runes - Prefixes, suffixes, and compound modifiers often do real narrowing work. Behavior-preserving, bounded, streaming, append-only, best-effort, zero-downtime, and read-only are not stylistic fluff. If you later build a digital spellbook, this lexicon becomes the substrate: each word-sense becomes a node, each spell becomes a path through nodes, each token stream can be rendered into a Gödel-style signature, and each clause circle can be visualized as a small coil of obligations and checks. For now, the main practical use is simpler: better words lead to better prompts, better designs, and better engineering conversations. A Simple Browsing Method • Start with the canon - If the task is common and high-stakes, the Public Canon will usually supply the first few runes you need. • Descend by house - Once the core terms are named, browse the relevant houses for local detail: database guarantees, runtime behavior, security wards, or release mechanics. • Pair force with shadow - For every guarantee word you cast, ask what failure word should stand beside it. Idempotent wants duplicate side effects; migration wants drift; concurrency wants race. • Use compounds late - Add tuning runes such as bounded, append-only, read-only, zero-downtime, or behavior-preserving only after the larger nouns are correct. • Write the spell in layers - Begin with title and objective, then add constraints, output contract, verification, and failure behavior until the risk feels bounded. A quick working pattern is: choose one or two architecture words, one or two state words, one guarantee word, one failure shadow, and one verification word. That small bundle is often enough to turn a vague request into an inspectable spell. Example bundle: interface + schema + idempotent + schema drift + contract test. VIII. The Lexicon of Houses The entries below are grouped by house, alphabetized within each house, and numbered continuously across the whole volume. Where a surface word belongs to more than one house, the house label in braces marks a distinct sense-entry. Each sense-entry can be used as a canonical token in spell numbering. ________________

Architecture, Abstraction, and Design These are the house-shaping words: the names by which software divides itself into parts, boundaries, layers, contracts, and responsibilities. They are magical because a single term in this house can change the expected structure of an entire system. To name something a service rather than a library, a pipeline rather than a monolith, an interface rather than an implementation, is already to constrain how people will reason, build, test, and deploy.

In this volume, entries are alphabetized within each house and given a sigil number. The sigil number can be used as the token id in a Gödel-style prompt encoding scheme later in the grimoire. [0001] abstraction — A deliberate forgetting of detail so larger structure can be reasoned about without drowning in mechanism. Shadow: hiding the only failure that matters. [0002] adapter — A negotiated translator between unlike shapes. Use it when two systems must meet without infecting one another. Shadow: adapter jungles that preserve confusion rather than resolve it. [0003] agent {Arch} — An acting word; a named locus of initiative that may observe, decide, and invoke tools. [0004] aggregate {Arch} — An order-word; it constrains how complexity is arranged rather than merely accumulated. [0005] anti-corruption layer — An order-word; it constrains how complexity is arranged rather than merely accumulated. [0006] API gateway — A threshold that centralizes entry, policy, and routing at the edge of a service world. Shadow: a convenience chokepoint that quietly becomes a monolith. [0007] architecture — A world-shaping word; it names the large order into which many smaller decisions must fit. [0008] artifact boundary — A composition-word; it lets many smaller parts behave as one larger form. [0009] assembler — A composition-word; it lets many smaller parts behave as one larger form. [0010] backbone — A boundary-word; it shapes how one part may touch another. [0011] backend — A structure-word; it gives responsibility a place to live. [0012] boundary — The line that says where one responsibility ends and another begins. Shadow: porous edges that smear blame, ownership, and test scope. [0013] bounded context — A protection against semantic bleed: the same word may not mean the same thing in every subsystem. Shadow: false unification through shared names. [0014] bridge — A boundary-word; it shapes how one part may touch another. [0015] broker {Arch} — A boundary-word; it shapes how one part may touch another. [0016] builder — An order-word; it constrains how complexity is arranged rather than merely accumulated. [0017] bus {Arch} — A composition-word; it lets many smaller parts behave as one larger form. [0018] capability {Arch} — A composition-word; it lets many smaller parts behave as one larger form. [0019] channel — A boundary-word; it shapes how one part may touch another. [0020] client {Arch} — An order-word; it constrains how complexity is arranged rather than merely accumulated. [0021] cluster {Arch} — A many-body word; several machines are treated as one operational unit. [0022] command bus — A boundary-word; it shapes how one part may touch another. [0023] component {Arch} — An order-word; it constrains how complexity is arranged rather than merely accumulated. [0024] composition — A structure-word; it gives responsibility a place to live. [0025] connector — An order-word; it constrains how complexity is arranged rather than merely accumulated. [0026] container {Arch} — An order-word; it constrains how complexity is arranged rather than merely accumulated. [0027] control plane {Arch} — A boundary-word; it shapes how one part may touch another. [0028] coordinator — A structure-word; it gives responsibility a place to live. [0029] core {Arch} — A boundary-word; it shapes how one part may touch another. [0030] coupling — The hidden tax paid when change in one place forces change elsewhere. Name it early if you want modularity to survive contact with reality. [0031] daemon {Arch} — A structure-word; it gives responsibility a place to live. [0032] data plane {Arch} — A composition-word; it lets many smaller parts behave as one larger form. [0033] decorator {Arch} — An order-word; it constrains how complexity is arranged rather than merely accumulated. [0034] dependency inversion — Stable policy should not kneel before unstable detail. Shadow: concrete dependencies hard-wired into places that should remain portable. [0035] dispatcher — An order-word; it constrains how complexity is arranged rather than merely accumulated. [0036] domain model — A boundary-word; it shapes how one part may touch another. [0037] edge service — A composition-word; it lets many smaller parts behave as one larger form. [0038] engine — A composition-word; it lets many smaller parts behave as one larger form. [0039] entrypoint — A structure-word; it gives responsibility a place to live. [0040] event bus — A structure-word; it gives responsibility a place to live. [0041] event handler — A structure-word; it gives responsibility a place to live. [0042] executor — An order-word; it constrains how complexity is arranged rather than merely accumulated. [0043] facade — A structure-word; it gives responsibility a place to live. [0044] factory — A structure-word; it gives responsibility a place to live. [0045] feature module — A composition-word; it lets many smaller parts behave as one larger form. [0046] frontend — A structure-word; it gives responsibility a place to live. [0047] gateway {Arch} — A composition-word; it lets many smaller parts behave as one larger form. [0048] graph — A composition-word; it lets many smaller parts behave as one larger form. [0049] handler — A composition-word; it lets many smaller parts behave as one larger form. [0050] hierarchy {Arch} — An order-word; it constrains how complexity is arranged rather than merely accumulated. [0051] hook — A boundary-word; it shapes how one part may touch another. [0052] host — A composition-word; it lets many smaller parts behave as one larger form. [0053] hub — An order-word; it constrains how complexity is arranged rather than merely accumulated. [0054] implementation {Arch} — A composition-word; it lets many smaller parts behave as one larger form. [0055] interface {Arch} — A disciplined seam that lets unlike bodies cooperate without swapping internal organs. Shadow: tight coupling and type bleed. [0056] interpreter {Arch} — A structure-word; it gives responsibility a place to live. [0057] kernel service — A composition-word; it lets many smaller parts behave as one larger form. [0058] layer — A boundary-word; it shapes how one part may touch another. [0059] library — A boundary-word; it shapes how one part may touch another. [0060] listener — A composition-word; it lets many smaller parts behave as one larger form. [0061] machine boundary — A boundary-word; it shapes how one part may touch another. [0062] mediator — A boundary-word; it shapes how one part may touch another. [0063] mesh {Arch} — A boundary-word; it shapes how one part may touch another. [0064] microservice — A partition word; a system is cut into independently deployed service bodies. [0065] middleware — A composition-word; it lets many smaller parts behave as one larger form. [0066] module {Arch} — A containment word; related definitions are packaged as one coherent unit. [0067] monolith — A composition-word; it lets many smaller parts behave as one larger form. [0068] namespace {Arch} — A boundary-word; it shapes how one part may touch another. [0069] node {Arch} — A composition-word; it lets many smaller parts behave as one larger form. [0070] observer — A structure-word; it gives responsibility a place to live. [0071] orchestrator — A conducting word; many services or tasks are coordinated into one larger procedure. [0072] package {Arch} — A structure-word; it gives responsibility a place to live. [0073] pipeline {Arch} — A procession word; work passes through ordered stages. [0074] platform — A boundary-word; it shapes how one part may touch another. [0075] plugin — An order-word; it constrains how complexity is arranged rather than merely accumulated. [0076] port {Arch} — A contact word; a defined point of communication or adaptation. [0077] presenter — A structure-word; it gives responsibility a place to live. [0078] process manager — A composition-word; it lets many smaller parts behave as one larger form. [0079] producer — A structure-word; it gives responsibility a place to live. [0080] projection — A boundary-word; it shapes how one part may touch another. [0081] protocol boundary — A composition-word; it lets many smaller parts behave as one larger form. [0082] proxy {Arch} — A stand-in word; one body speaks or receives on behalf of another. [0083] queue {Arch} — A boundary-word; it shapes how one part may touch another. [0084] reactor — A structure-word; it gives responsibility a place to live. [0085] receiver — A boundary-word; it shapes how one part may touch another. [0086] registry — A boundary-word; it shapes how one part may touch another. [0087] repository {Arch} — A custody word; an official place from which versions or entities are retrieved. [0088] resource boundary — A structure-word; it gives responsibility a place to live. [0089] router {Arch} — A boundary-word; it shapes how one part may touch another. [0090] scheduler — A tempo word; it apportions time among contenders. [0091] seam — A composition-word; it lets many smaller parts behave as one larger form. [0092] service — A duty word; a stable capability exposed for repeated use by others. [0093] service mesh {Arch} — A side-channel governance word for service-to-service traffic. [0094] session boundary — A structure-word; it gives responsibility a place to live. [0095] shard {Arch} — A splitting word; one logical body is divided across multiple partitions. [0096] shim — A boundary-word; it shapes how one part may touch another. [0097] singleton — An order-word; it constrains how complexity is arranged rather than merely accumulated. [0098] source of truth — An authority word; one record or service is treated as canonical. [0099] stack {Arch} — A layering word; order matters and the most recent thing is nearest the top. [0100] stage {Arch} — A structure-word; it gives responsibility a place to live. [0101] state machine — A lawful-transition word; only certain moves are allowed from each state. [0102] strategy — An order-word; it constrains how complexity is arranged rather than merely accumulated. [0103] subsystem — An order-word; it constrains how complexity is arranged rather than merely accumulated. [0104] surface — A boundary-word; it shapes how one part may touch another. [0105] system — A boundary-word; it shapes how one part may touch another. [0106] template method — A boundary-word; it shapes how one part may touch another. [0107] tree — A structure-word; it gives responsibility a place to live. [0108] use case — A boundary-word; it shapes how one part may touch another. [0109] value object — A structure-word; it gives responsibility a place to live. [0110] worker — A labor word; a designated body performs tasks delegated by some larger system. [0111] workflow — An order-word; it constrains how complexity is arranged rather than merely accumulated. [0112] wrapper — A boundary-word; it shapes how one part may touch another. ________________

Language, Semantics, and Formal Shape These are the grammar words and law words of programming languages. They are not merely labels: they determine how thought is permitted to take form. A change from expression to statement, from mutable to immutable, from dynamic dispatch to static dispatch, from trait to class or from class to interface, can reorder what a language lets the programmer guarantee. [0113] abstract class — A semantics word; it alters what symbols are allowed to mean in practice. [0114] alias — A semantics word; it alters what symbols are allowed to mean in practice. [0115] annotation — A shape-of-thought word; it influences how programs are written and reasoned about. [0116] argument — A shape-of-thought word; it influences how programs are written and reasoned about. [0117] arity — A law-of-form word; it changes what the language can guarantee. [0118] assembly — A grammar-word; it shapes how meaning is expressed to humans and machines. [0119] assertion {Lang} — A grammar-word; it shapes how meaning is expressed to humans and machines. [0120] AST — A grammar-word; it shapes how meaning is expressed to humans and machines. [0121] attribute — A grammar-word; it shapes how meaning is expressed to humans and machines. [0122] binding — A shape-of-thought word; it influences how programs are written and reasoned about. [0123] borrow {Lang} — A shape-of-thought word; it influences how programs are written and reasoned about. [0124] borrow checker — A grammar-word; it shapes how meaning is expressed to humans and machines. [0125] bytecode — A shape-of-thought word; it influences how programs are written and reasoned about. [0126] capture — A grammar-word; it shapes how meaning is expressed to humans and machines. [0127] cast — A shape-of-thought word; it influences how programs are written and reasoned about. [0128] class — A shape word for bundled state and behavior. [0129] closure — A capture word; it carries surrounding bindings forward with executable intent. [0130] coercion — A semantics word; it alters what symbols are allowed to mean in practice. [0131] comment — A shape-of-thought word; it influences how programs are written and reasoned about. [0132] compile-time — A law-of-form word; it changes what the language can guarantee. [0133] compiler — A shape-of-thought word; it influences how programs are written and reasoned about. [0134] constant — A semantics word; it alters what symbols are allowed to mean in practice. [0135] constraint {Lang} — A bounding word; it removes degrees of freedom in order to improve correctness. [0136] constructor — A semantics word; it alters what symbols are allowed to mean in practice. [0137] contravariance — A grammar-word; it shapes how meaning is expressed to humans and machines. [0138] covariance — A shape-of-thought word; it influences how programs are written and reasoned about. [0139] currying — A shape-of-thought word; it influences how programs are written and reasoned about. [0140] declaration — A semantics word; it alters what symbols are allowed to mean in practice. [0141] decorator {Lang} — A shape-of-thought word; it influences how programs are written and reasoned about. [0142] default — A law-of-form word; it changes what the language can guarantee. [0143] definition — A law-of-form word; it changes what the language can guarantee. [0144] denotation — A law-of-form word; it changes what the language can guarantee. [0145] destructor {Lang} — A shape-of-thought word; it influences how programs are written and reasoned about. [0146] dispatch {Lang} — A grammar-word; it shapes how meaning is expressed to humans and machines. [0147] domain-specific language — A shape-of-thought word; it influences how programs are written and reasoned about. [0148] dynamic scope — A shape-of-thought word; it influences how programs are written and reasoned about. [0149] effect — A law-of-form word; it changes what the language can guarantee. [0150] enum — A law-of-form word; it changes what the language can guarantee. [0151] evaluation {Lang} — A grammar-word; it shapes how meaning is expressed to humans and machines. [0152] export {Lang} — A semantics word; it alters what symbols are allowed to mean in practice. [0153] expression — A grammar-word; it shapes how meaning is expressed to humans and machines. [0154] extern — A semantics word; it alters what symbols are allowed to mean in practice. [0155] field {Lang} — A grammar-word; it shapes how meaning is expressed to humans and machines. [0156] final — A semantics word; it alters what symbols are allowed to mean in practice. [0157] function — A callable word; given inputs, it yields outputs by a named rule. [0158] generic {Lang} — A law-of-form word; it changes what the language can guarantee. [0159] grammar — A shape-of-thought word; it influences how programs are written and reasoned about. [0160] higher-order function — A semantics word; it alters what symbols are allowed to mean in practice. [0161] identifier — A shape-of-thought word; it influences how programs are written and reasoned about. [0162] impl — A semantics word; it alters what symbols are allowed to mean in practice. [0163] implementation {Lang} — A semantics word; it alters what symbols are allowed to mean in practice. [0164] import — A shape-of-thought word; it influences how programs are written and reasoned about. [0165] include — A grammar-word; it shapes how meaning is expressed to humans and machines. [0166] inference — A shape-of-thought word; it influences how programs are written and reasoned about. [0167] inheritance — A semantics word; it alters what symbols are allowed to mean in practice. [0168] inline {Lang} — A shape-of-thought word; it influences how programs are written and reasoned about. [0169] instruction {Lang} — A semantics word; it alters what symbols are allowed to mean in practice. [0170] interface {Lang} — A boundary word; it lets different bodies touch through a disciplined seam. [0171] interpreter {Lang} — A grammar-word; it shapes how meaning is expressed to humans and machines. [0172] IR — A shape-of-thought word; it influences how programs are written and reasoned about. [0173] keyword — A law-of-form word; it changes what the language can guarantee. [0174] lambda — A law-of-form word; it changes what the language can guarantee. [0175] lexical scope — A grammar-word; it shapes how meaning is expressed to humans and machines. [0176] lifetime {Lang} — A shape-of-thought word; it influences how programs are written and reasoned about. [0177] linker — A law-of-form word; it changes what the language can guarantee. [0178] literal — A law-of-form word; it changes what the language can guarantee. [0179] loader — A shape-of-thought word; it influences how programs are written and reasoned about. [0180] macro — A semantics word; it alters what symbols are allowed to mean in practice. [0181] metaprogramming — A semantics word; it alters what symbols are allowed to mean in practice. [0182] method — A law-of-form word; it changes what the language can guarantee. [0183] mixin — A law-of-form word; it changes what the language can guarantee. [0184] module {Lang} — A containment word; related definitions are packaged as one coherent unit. [0185] monomorphization — A law-of-form word; it changes what the language can guarantee. [0186] mutability — A grammar-word; it shapes how meaning is expressed to humans and machines. [0187] name resolution — A law-of-form word; it changes what the language can guarantee. [0188] namespace {Lang} — A law-of-form word; it changes what the language can guarantee. [0189] object — A shape-of-thought word; it influences how programs are written and reasoned about. [0190] opcode {Lang} — A semantics word; it alters what symbols are allowed to mean in practice. [0191] overload — A grammar-word; it shapes how meaning is expressed to humans and machines. [0192] override — A grammar-word; it shapes how meaning is expressed to humans and machines. [0193] ownership — A shape-of-thought word; it influences how programs are written and reasoned about. [0194] package {Lang} — A grammar-word; it shapes how meaning is expressed to humans and machines. [0195] parameter — A law-of-form word; it changes what the language can guarantee. [0196] parametric polymorphism — A shape-of-thought word; it influences how programs are written and reasoned about. [0197] parser — A law-of-form word; it changes what the language can guarantee. [0198] pattern — A semantics word; it alters what symbols are allowed to mean in practice. [0199] pattern matching — A law-of-form word; it changes what the language can guarantee. [0200] polymorphism — A shape-of-thought word; it influences how programs are written and reasoned about. [0201] procedure {Lang} — A method word; not just what to do, but in what order to do it. [0202] program — A grammar-word; it shapes how meaning is expressed to humans and machines. [0203] property {Lang} — A law-of-form word; it changes what the language can guarantee. [0204] protected — A semantics word; it alters what symbols are allowed to mean in practice. [0205] public — A shape-of-thought word; it influences how programs are written and reasoned about. [0206] purity — A law-of-form word; it changes what the language can guarantee. [0207] qualified name — A law-of-form word; it changes what the language can guarantee. [0208] readonly — A semantics word; it alters what symbols are allowed to mean in practice. [0209] record {Lang} — A shape-of-thought word; it influences how programs are written and reasoned about. [0210] reference {Lang} — A shape-of-thought word; it influences how programs are written and reasoned about. [0211] referential transparency — A shape-of-thought word; it influences how programs are written and reasoned about. [0212] reflection — A shape-of-thought word; it influences how programs are written and reasoned about. [0213] resolution — A grammar-word; it shapes how meaning is expressed to humans and machines. [0214] return type — A semantics word; it alters what symbols are allowed to mean in practice. [0215] runtime type — A semantics word; it alters what symbols are allowed to mean in practice. [0216] scope {Lang} — A semantics word; it alters what symbols are allowed to mean in practice. [0217] sealed — A semantics word; it alters what symbols are allowed to mean in practice. [0218] semantics — A shape-of-thought word; it influences how programs are written and reasoned about. [0219] signature {Lang} — A proving word; identity or contract is made checkable. [0220] source code — A grammar-word; it shapes how meaning is expressed to humans and machines. [0221] specialization — A shape-of-thought word; it influences how programs are written and reasoned about. [0222] statement — A law-of-form word; it changes what the language can guarantee. [0223] static dispatch — A grammar-word; it shapes how meaning is expressed to humans and machines. [0224] strictness — A semantics word; it alters what symbols are allowed to mean in practice. [0225] struct {Lang} — A law-of-form word; it changes what the language can guarantee. [0226] subtype — A grammar-word; it shapes how meaning is expressed to humans and machines. [0227] supertype — A law-of-form word; it changes what the language can guarantee. [0228] symbol — A semantics word; it alters what symbols are allowed to mean in practice. [0229] syntax — A shape-of-thought word; it influences how programs are written and reasoned about. [0230] template {Lang} — A grammar-word; it shapes how meaning is expressed to humans and machines. [0231] theorem {Lang} — A grammar-word; it shapes how meaning is expressed to humans and machines. [0232] token {Lang} — A countable unit of text or symbol used for parsing, modeling, or encoding. [0233] trait — A grammar-word; it shapes how meaning is expressed to humans and machines. [0234] transpiler — A grammar-word; it shapes how meaning is expressed to humans and machines. [0235] tuple {Lang} — A semantics word; it alters what symbols are allowed to mean in practice. [0236] type — A shape-and-law word; it governs what operations are permitted and what meanings attach. [0237] type alias — A grammar-word; it shapes how meaning is expressed to humans and machines. [0238] type inference — A law-of-form word; it changes what the language can guarantee. [0239] type system — A shape-of-thought word; it influences how programs are written and reasoned about. [0240] typechecker — A shape-of-thought word; it influences how programs are written and reasoned about. [0241] typeclass — A grammar-word; it shapes how meaning is expressed to humans and machines. [0242] unification — A law-of-form word; it changes what the language can guarantee. [0243] union — A law-of-form word; it changes what the language can guarantee. [0244] value — A law-of-form word; it changes what the language can guarantee. [0245] variance — A law-of-form word; it changes what the language can guarantee. [0246] virtual — A shape-of-thought word; it influences how programs are written and reasoned about. [0247] visibility — A grammar-word; it shapes how meaning is expressed to humans and machines. [0248] visitor — A grammar-word; it shapes how meaning is expressed to humans and machines. [0249] where-clause — A law-of-form word; it changes what the language can guarantee. ________________

Data, State, and Representation These are the matter words of software: the names of things that can be held, moved, indexed, transformed, cached, persisted, and compared. Data words are magical because they determine what a system can remember and what kinds of transformations feel natural inside it. [0250] address — A storage-word; it determines how meaning is carried through memory or transport. [0251] aggregate state — A matter-word; it names something that can be held, moved, or compared. [0252] array — A shape-of-state word; it influences what later transformations are easy or hard. [0253] bag — A storage-word; it determines how meaning is carried through memory or transport. [0254] binary blob — A matter-word; it names something that can be held, moved, or compared. [0255] bit — A shape-of-state word; it influences what later transformations are easy or hard. [0256] bitmap — A representation-word; it gives state a vessel or surface. [0257] blob — A shape-of-state word; it influences what later transformations are easy or hard. [0258] block {Data} — A shape-of-state word; it influences what later transformations are easy or hard. [0259] Bloom filter — A shape-of-state word; it influences what later transformations are easy or hard. [0260] body — A storage-word; it determines how meaning is carried through memory or transport. [0261] book-keeping field — A shape-of-state word; it influences what later transformations are easy or hard. [0262] bucket {Data} — A storage-word; it determines how meaning is carried through memory or transport. [0263] buffer — A storage-word; it determines how meaning is carried through memory or transport. [0264] byte — A matter-word; it names something that can be held, moved, or compared. [0265] cache entry — A storage-word; it determines how meaning is carried through memory or transport. [0266] canonical form {Data} — A normalization word; many possible surfaces are forced into one agreed shape. [0267] cell — A matter-word; it names something that can be held, moved, or compared. [0268] checksum — A shape-of-state word; it influences what later transformations are easy or hard. [0269] chunk — A representation-word; it gives state a vessel or surface. [0270] column {Data} — A storage-word; it determines how meaning is carried through memory or transport. [0271] composite value — A matter-word; it names something that can be held, moved, or compared. [0272] config — A storage-word; it determines how meaning is carried through memory or transport. [0273] constant pool — A matter-word; it names something that can be held, moved, or compared. [0274] content — A shape-of-state word; it influences what later transformations are easy or hard. [0275] context object — A matter-word; it names something that can be held, moved, or compared. [0276] cookie — A storage-word; it determines how meaning is carried through memory or transport. [0277] corpus — A matter-word; it names something that can be held, moved, or compared. [0278] counter {Data} — A matter-word; it names something that can be held, moved, or compared. [0279] credential {Data} — A shape-of-state word; it influences what later transformations are easy or hard. [0280] cursor {Data} — A storage-word; it determines how meaning is carried through memory or transport. [0281] data frame — A representation-word; it gives state a vessel or surface. [0282] data point — A matter-word; it names something that can be held, moved, or compared. [0283] dataset — A storage-word; it determines how meaning is carried through memory or transport. [0284] datum — A shape-of-state word; it influences what later transformations are easy or hard. [0285] delta — A storage-word; it determines how meaning is carried through memory or transport. [0286] dense vector — A storage-word; it determines how meaning is carried through memory or transport. [0287] descriptor — A shape-of-state word; it influences what later transformations are easy or hard. [0288] dictionary — A storage-word; it determines how meaning is carried through memory or transport. [0289] digest {Data} — A matter-word; it names something that can be held, moved, or compared. [0290] document — A shape-of-state word; it influences what later transformations are easy or hard. [0291] edge {Data} — A representation-word; it gives state a vessel or surface. [0292] element — A storage-word; it determines how meaning is carried through memory or transport. [0293] embedding {Data} — A closeness word; it places meaning into geometry. [0294] entity — A representation-word; it gives state a vessel or surface. [0295] enum value — A storage-word; it determines how meaning is carried through memory or transport. [0296] envelope — A storage-word; it determines how meaning is carried through memory or transport. [0297] event — A happening word; something occurred and may now be recorded, reacted to, or replayed. [0298] event log — A matter-word; it names something that can be held, moved, or compared. [0299] fact — A storage-word; it determines how meaning is carried through memory or transport. [0300] feature — A matter-word; it names something that can be held, moved, or compared. [0301] field {Data} — A matter-word; it names something that can be held, moved, or compared. [0302] fingerprint — A matter-word; it names something that can be held, moved, or compared. [0303] flag — A storage-word; it determines how meaning is carried through memory or transport. [0304] frame {Data} — A shape-of-state word; it influences what later transformations are easy or hard. [0305] handle {Data} — A matter-word; it names something that can be held, moved, or compared. [0306] hash {Data} — A condensation word; arbitrary input becomes a fixed fingerprint. [0307] hash map — A storage-word; it determines how meaning is carried through memory or transport. [0308] header — A representation-word; it gives state a vessel or surface. [0309] heap record — A representation-word; it gives state a vessel or surface. [0310] index {Data} — A retrieval word; it makes later access faster by storing an alternate path to data. [0311] index key — A representation-word; it gives state a vessel or surface. [0312] item — A shape-of-state word; it influences what later transformations are easy or hard. [0313] iterator — A storage-word; it determines how meaning is carried through memory or transport. [0314] journal — A shape-of-state word; it influences what later transformations are easy or hard. [0315] key {Data} — A representation-word; it gives state a vessel or surface. [0316] key-value pair — A shape-of-state word; it influences what later transformations are easy or hard. [0317] ledger — A shape-of-state word; it influences what later transformations are easy or hard. [0318] list — A matter-word; it names something that can be held, moved, or compared. [0319] literal value — A storage-word; it determines how meaning is carried through memory or transport. [0320] map {Data} — A storage-word; it determines how meaning is carried through memory or transport. [0321] matrix — A representation-word; it gives state a vessel or surface. [0322] message — A carrier word; intent or state is wrapped for transport between components. [0323] metadata — A representation-word; it gives state a vessel or surface. [0324] model {Data} — A representative word; a simplified structure stands in for a larger reality. [0325] multimap — A representation-word; it gives state a vessel or surface. [0326] node {Data} — A storage-word; it determines how meaning is carried through memory or transport. [0327] null — A shape-of-state word; it influences what later transformations are easy or hard. [0328] object state — A matter-word; it names something that can be held, moved, or compared. [0329] offset — A shape-of-state word; it influences what later transformations are easy or hard. [0330] page {Data} — A representation-word; it gives state a vessel or surface. [0331] pair — A matter-word; it names something that can be held, moved, or compared. [0332] payload — A storage-word; it determines how meaning is carried through memory or transport. [0333] pointer {Data} — A location word; it does not hold the thing, but where the thing may be found. [0334] pool — A storage-word; it determines how meaning is carried through memory or transport. [0335] property {Data} — A representation-word; it gives state a vessel or surface. [0336] queue element — A shape-of-state word; it influences what later transformations are easy or hard. [0337] range — A representation-word; it gives state a vessel or surface. [0338] record {Data} — A shape-of-state word; it influences what later transformations are easy or hard. [0339] reference {Data} — A shape-of-state word; it influences what later transformations are easy or hard. [0340] relation {Data} — A storage-word; it determines how meaning is carried through memory or transport. [0341] representation — A shape-of-state word; it influences what later transformations are easy or hard. [0342] resource — A bounded-thing word; something that must be acquired, used, and released. [0343] revision {Data} — A shape-of-state word; it influences what later transformations are easy or hard. [0344] ring buffer — A storage-word; it determines how meaning is carried through memory or transport. [0345] row {Data} — A matter-word; it names something that can be held, moved, or compared. [0346] scalar — A storage-word; it determines how meaning is carried through memory or transport. [0347] schema {Data} — The declared shape of stored meaning. Shadow: drift, silent coercion, and backward-incompatible surprise. [0348] secret {Data} — A guarded-value word meant to remain hidden except to the few who must know it. [0349] segment {Data} — A shape-of-state word; it influences what later transformations are easy or hard. [0350] sequence — A representation-word; it gives state a vessel or surface. [0351] series — A shape-of-state word; it influences what later transformations are easy or hard. [0352] session — A matter-word; it names something that can be held, moved, or compared. [0353] set — A matter-word; it names something that can be held, moved, or compared. [0354] sketch — A storage-word; it determines how meaning is carried through memory or transport. [0355] slice — A matter-word; it names something that can be held, moved, or compared. [0356] snapshot — A matter-word; it names something that can be held, moved, or compared. [0357] sparse vector — A representation-word; it gives state a vessel or surface. [0358] stack item — A representation-word; it gives state a vessel or surface. [0359] state — A condition word; what the system is like right now. [0360] stream item — A shape-of-state word; it influences what later transformations are easy or hard. [0361] string — A shape-of-state word; it influences what later transformations are easy or hard. [0362] struct {Data} — A representation-word; it gives state a vessel or surface. [0363] table {Data} — A matter-word; it names something that can be held, moved, or compared. [0364] tensor — A shape-of-state word; it influences what later transformations are easy or hard. [0365] token {Data} — A countable unit of text or symbol used for parsing, modeling, or encoding. [0366] tree node — A storage-word; it determines how meaning is carried through memory or transport. [0367] trie — A matter-word; it names something that can be held, moved, or compared. [0368] tuple {Data} — A storage-word; it determines how meaning is carried through memory or transport. [0369] vector — A shape-of-state word; it influences what later transformations are easy or hard. [0370] view {Data} — A shape-of-state word; it influences what later transformations are easy or hard. [0371] window — A matter-word; it names something that can be held, moved, or compared. ________________

Transformation, Algorithms, and Working Verbs This house contains movement words: verbs by which software changes form, order, encoding, granularity, or state. They are magical because they say not just what something is, but what it will become after contact with a procedure. [0372] aggregate {Verb} — A procedure-word; it tells software what kind of transformation is underway. [0373] amortize — A procedure-word; it tells software what kind of transformation is underway. [0374] analyze — A change-word; it alters form, order, or representation. [0375] annotate — An alchemical word; it moves data from one shape into another. [0376] approximate {Verb} — An alchemical word; it moves data from one shape into another. [0377] archive — An alchemical word; it moves data from one shape into another. [0378] assemble {Verb} — A change-word; it alters form, order, or representation. [0379] batch — An alchemical word; it moves data from one shape into another. [0380] bucket {Verb} — An alchemical word; it moves data from one shape into another. [0381] canonicalize — A change-word; it alters form, order, or representation. [0382] classify — An alchemical word; it moves data from one shape into another. [0383] clean — A procedure-word; it tells software what kind of transformation is underway. [0384] clone — A work-word; it describes how material is processed into some next state. [0385] coalesce — A procedure-word; it tells software what kind of transformation is underway. [0386] collect — An alchemical word; it moves data from one shape into another. [0387] compact — A procedure-word; it tells software what kind of transformation is underway. [0388] compare — A procedure-word; it tells software what kind of transformation is underway. [0389] compile {Verb} — A transmutation word; it transforms one language into another fit for execution. [0390] compress — A change-word; it alters form, order, or representation. [0391] compute — A work-word; it describes how material is processed into some next state. [0392] condense — A procedure-word; it tells software what kind of transformation is underway. [0393] convert — A work-word; it describes how material is processed into some next state. [0394] correlate — A work-word; it describes how material is processed into some next state. [0395] decode — A change-word; it alters form, order, or representation. [0396] decrypt {Verb} — An unsealing word; protected meaning becomes legible again under the right key. [0397] deduplicate — A change-word; it alters form, order, or representation. [0398] defer {Verb} — An alchemical word; it moves data from one shape into another. [0399] delete — A procedure-word; it tells software what kind of transformation is underway. [0400] denoise — A procedure-word; it tells software what kind of transformation is underway. [0401] derive — A procedure-word; it tells software what kind of transformation is underway. [0402] deserialize — A work-word; it describes how material is processed into some next state. [0403] detect — A work-word; it describes how material is processed into some next state. [0404] diff {Verb} — A difference word; it names what changed between two states. [0405] digest {Verb} — A change-word; it alters form, order, or representation. [0406] dispatch {Verb} — A change-word; it alters form, order, or representation. [0407] distribute — A procedure-word; it tells software what kind of transformation is underway. [0408] drain — An alchemical word; it moves data from one shape into another. [0409] drop — A work-word; it describes how material is processed into some next state. [0410] encode — An alchemical word; it moves data from one shape into another. [0411] encrypt {Verb} — A warding word; it hides meaning from everyone except the right holder of the key. [0412] enumerate — An alchemical word; it moves data from one shape into another. [0413] evaluate — A procedure-word; it tells software what kind of transformation is underway. [0414] expand — A change-word; it alters form, order, or representation. [0415] explode — A work-word; it describes how material is processed into some next state. [0416] export {Verb} — An alchemical word; it moves data from one shape into another. [0417] extract — A procedure-word; it tells software what kind of transformation is underway. [0418] fetch — An alchemical word; it moves data from one shape into another. [0419] filter — An alchemical word; it moves data from one shape into another. [0420] flatten — An alchemical word; it moves data from one shape into another. [0421] fold — A work-word; it describes how material is processed into some next state. [0422] format — A work-word; it describes how material is processed into some next state. [0423] fuse — A procedure-word; it tells software what kind of transformation is underway. [0424] generate — A procedure-word; it tells software what kind of transformation is underway. [0425] group — A work-word; it describes how material is processed into some next state. [0426] hash {Verb} — A condensation word; arbitrary input becomes a fixed fingerprint. [0427] hoist — A procedure-word; it tells software what kind of transformation is underway. [0428] hydrate — A work-word; it describes how material is processed into some next state. [0429] infer — A consequence word; it derives hidden structure from visible evidence. [0430] inline {Verb} — A procedure-word; it tells software what kind of transformation is underway. [0431] instrument — A work-word; it describes how material is processed into some next state. [0432] integrate — A procedure-word; it tells software what kind of transformation is underway. [0433] interpolate — A procedure-word; it tells software what kind of transformation is underway. [0434] invert — A change-word; it alters form, order, or representation. [0435] isolate {Verb} — A work-word; it describes how material is processed into some next state. [0436] join {Verb} — A union word; separate streams, sets, or histories are brought into one result. [0437] lex — A work-word; it describes how material is processed into some next state. [0438] link — A joining word; separate symbols are resolved into one executable body. [0439] map {Verb} — An alchemical word; it moves data from one shape into another. [0440] marshal — A change-word; it alters form, order, or representation. [0441] materialize — A procedure-word; it tells software what kind of transformation is underway. [0442] measure — An alchemical word; it moves data from one shape into another. [0443] memoize — An alchemical word; it moves data from one shape into another. [0444] merge {Verb} — A reconciliation word; separate lines of change are brought back together. [0445] migrate — A work-word; it describes how material is processed into some next state. [0446] minify — A change-word; it alters form, order, or representation. [0447] model {Verb} — A representative word; a simplified structure stands in for a larger reality. [0448] normalize — A regularizing word; irregular forms are bent toward a standard shape. [0449] optimize — A work-word; it describes how material is processed into some next state. [0450] paginate — A work-word; it describes how material is processed into some next state. [0451] parallelize — A work-word; it describes how material is processed into some next state. [0452] parse — A structure-finding word; raw symbols become an ordered tree or sequence. [0453] partition {Verb} — An alchemical word; it moves data from one shape into another. [0454] patch {Verb} — A repair word; a bounded alteration is applied to an existing body. [0455] pipeline {Verb} — A procession word; work passes through ordered stages. [0456] prepare — A procedure-word; it tells software what kind of transformation is underway. [0457] preprocess — An alchemical word; it moves data from one shape into another. [0458] profile — A hotspot-seeking word; it reveals where time or resources are actually spent. [0459] project — A procedure-word; it tells software what kind of transformation is underway. [0460] prune — An alchemical word; it moves data from one shape into another. [0461] quantize — A work-word; it describes how material is processed into some next state. [0462] query — An asking word; it requests structure or records from stored state. [0463] rasterize — A work-word; it describes how material is processed into some next state. [0464] rebalance — A work-word; it describes how material is processed into some next state. [0465] reconcile — A change-word; it alters form, order, or representation. [0466] reconstruct — A change-word; it alters form, order, or representation. [0467] reduce — A change-word; it alters form, order, or representation. [0468] refactor — A reshaping word; structure changes while intended behavior is preserved. [0469] reformat — A change-word; it alters form, order, or representation. [0470] rehydrate — A change-word; it alters form, order, or representation. [0471] reindex — A procedure-word; it tells software what kind of transformation is underway. [0472] render — A change-word; it alters form, order, or representation. [0473] reorder — A procedure-word; it tells software what kind of transformation is underway. [0474] replicate — A work-word; it describes how material is processed into some next state. [0475] reshape — A change-word; it alters form, order, or representation. [0476] resolve — A change-word; it alters form, order, or representation. [0477] restore {Verb} — A change-word; it alters form, order, or representation. [0478] rewrite — An alchemical word; it moves data from one shape into another. [0479] sample — An alchemical word; it moves data from one shape into another. [0480] sanitize — A procedure-word; it tells software what kind of transformation is underway. [0481] scan {Verb} — A work-word; it describes how material is processed into some next state. [0482] schedule {Verb} — A work-word; it describes how material is processed into some next state. [0483] search — An alchemical word; it moves data from one shape into another. [0484] segment {Verb} — A procedure-word; it tells software what kind of transformation is underway. [0485] serialize — A flattening word; structured state is turned into a transportable sequence. [0486] shard {Verb} — A splitting word; one logical body is divided across multiple partitions. [0487] shuffle — A work-word; it describes how material is processed into some next state. [0488] sign {Verb} — A sealing word; origin or integrity is bound cryptographically to content. [0489] smooth — An alchemical word; it moves data from one shape into another. [0490] sort — A change-word; it alters form, order, or representation. [0491] specialize — A work-word; it describes how material is processed into some next state. [0492] split — A change-word; it alters form, order, or representation. [0493] stage {Verb} — A change-word; it alters form, order, or representation. [0494] stream {Verb} — A flow word; values arrive over time rather than all at once. [0495] summarize — A work-word; it describes how material is processed into some next state. [0496] synthesize — An alchemical word; it moves data from one shape into another. [0497] tokenize — A work-word; it describes how material is processed into some next state. [0498] trace {Verb} — A path-of-execution word preserved for later reading. [0499] train — An alchemical word; it moves data from one shape into another. [0500] transform — A change word; the material remains connected to its former self while taking new form. [0501] translate — An alchemical word; it moves data from one shape into another. [0502] transpose — A procedure-word; it tells software what kind of transformation is underway. [0503] truncate — An alchemical word; it moves data from one shape into another. [0504] tune — A change-word; it alters form, order, or representation. [0505] unmarshal — A procedure-word; it tells software what kind of transformation is underway. [0506] unpack — An alchemical word; it moves data from one shape into another. [0507] update — A procedure-word; it tells software what kind of transformation is underway. [0508] validate {Verb} — A gatekeeping word; inputs or outputs are checked against an expected form. [0509] vectorize — A procedure-word; it tells software what kind of transformation is underway. [0510] verify — A truth-checking verb; it demands evidence that a claim or result actually holds. [0511] zip — A procedure-word; it tells software what kind of transformation is underway. ________________

Control Flow, Coordination, and Temporal Logic These are the tempo words of software. They decide when work begins, branches, repeats, waits, wakes, cancels, or concludes. In programming practice, bad outcomes often come not from wrong nouns but from wrong ordering. This house therefore governs sequence, contingency, and time. [0512] abort — A tempo-word; it governs order, waiting, branching, or repetition. [0513] acknowledge — A tempo-word; it governs order, waiting, branching, or repetition. [0514] async — A time-binding word; it changes when an action may proceed. [0515] await — A suspension word; it pauses one flow so other work may continue. [0516] backoff {Ctrl} — A tempo-word; it governs order, waiting, branching, or repetition. [0517] barrier {Ctrl} — A rendezvous word; no party crosses until all required parties arrive. [0518] block {Ctrl} — A coordination word; it manages concurrency, interruption, or flow. [0519] branch {Ctrl} — A divergence word; execution or history splits into alternate paths. [0520] break — A sequencing word; it decides what happens next and under what condition. [0521] callback — A sequencing word; it decides what happens next and under what condition. [0522] cancel — A time-binding word; it changes when an action may proceed. [0523] case — A tempo-word; it governs order, waiting, branching, or repetition. [0524] catch — A coordination word; it manages concurrency, interruption, or flow. [0525] chain — A coordination word; it manages concurrency, interruption, or flow. [0526] choose — A sequencing word; it decides what happens next and under what condition. [0527] circuit breaker — A coordination word; it manages concurrency, interruption, or flow. [0528] clause — A sequencing word; it decides what happens next and under what condition. [0529] continue — A sequencing word; it decides what happens next and under what condition. [0530] coroutine — A tempo-word; it governs order, waiting, branching, or repetition. [0531] countdown — A sequencing word; it decides what happens next and under what condition. [0532] cycle — A tempo-word; it governs order, waiting, branching, or repetition. [0533] debounce — A sequencing word; it decides what happens next and under what condition. [0534] defer {Ctrl} — A time-binding word; it changes when an action may proceed. [0535] delay — A coordination word; it manages concurrency, interruption, or flow. [0536] dispatch {Ctrl} — A tempo-word; it governs order, waiting, branching, or repetition. [0537] do — A coordination word; it manages concurrency, interruption, or flow. [0538] else — A sequencing word; it decides what happens next and under what condition. [0539] enqueue — A tempo-word; it governs order, waiting, branching, or repetition. [0540] event loop — A circulation word; work is accepted, queued, and resumed by recurrent inspection. [0541] fallback {Ctrl} — A tempo-word; it governs order, waiting, branching, or repetition. [0542] fan-in — A sequencing word; it decides what happens next and under what condition. [0543] fan-out {Ctrl} — A time-binding word; it changes when an action may proceed. [0544] finally — A coordination word; it manages concurrency, interruption, or flow. [0545] fire-and-forget — A time-binding word; it changes when an action may proceed. [0546] flow control — A sequencing word; it decides what happens next and under what condition. [0547] for — A coordination word; it manages concurrency, interruption, or flow. [0548] fork {Ctrl} — A time-binding word; it changes when an action may proceed. [0549] future — A coordination word; it manages concurrency, interruption, or flow. [0550] gate — A permission word; passage occurs only when conditions hold. [0551] guard — A coordination word; it manages concurrency, interruption, or flow. [0552] halt — A sequencing word; it decides what happens next and under what condition. [0553] heartbeat {Ctrl} — A tempo-word; it governs order, waiting, branching, or repetition. [0554] if — A coordination word; it manages concurrency, interruption, or flow. [0555] iterate — A time-binding word; it changes when an action may proceed. [0556] join {Ctrl} — A union word; separate streams, sets, or histories are brought into one result. [0557] jump — A tempo-word; it governs order, waiting, branching, or repetition. [0558] latch — A tempo-word; it governs order, waiting, branching, or repetition. [0559] loop — A time-binding word; it changes when an action may proceed. [0560] match — A sequencing word; it decides what happens next and under what condition. [0561] mutex — An exclusion word; only one actor may enter the critical region at a time. [0562] notify — A sequencing word; it decides what happens next and under what condition. [0563] once — A sequencing word; it decides what happens next and under what condition. [0564] parallel {Ctrl} — A sequencing word; it decides what happens next and under what condition. [0565] pause — A time-binding word; it changes when an action may proceed. [0566] poll {Ctrl} — A coordination word; it manages concurrency, interruption, or flow. [0567] preempt — A sequencing word; it decides what happens next and under what condition. [0568] priority — A time-binding word; it changes when an action may proceed. [0569] process {Ctrl} — A sovereignty word; an executing program with its own protected address space. [0570] promise — A coordination word; it manages concurrency, interruption, or flow. [0571] queue {Ctrl} — A sequencing word; it decides what happens next and under what condition. [0572] race window — A coordination word; it manages concurrency, interruption, or flow. [0573] recurse — A sequencing word; it decides what happens next and under what condition. [0574] repeat — A sequencing word; it decides what happens next and under what condition. [0575] reserve — A tempo-word; it governs order, waiting, branching, or repetition. [0576] retry {Ctrl} — Failure does not necessarily end the ritual; policy may permit another attempt. Shadow: blind repetition against a broken precondition. [0577] return — A tempo-word; it governs order, waiting, branching, or repetition. [0578] round-robin — A coordination word; it manages concurrency, interruption, or flow. [0579] schedule {Ctrl} — A sequencing word; it decides what happens next and under what condition. [0580] select {Ctrl} — A tempo-word; it governs order, waiting, branching, or repetition. [0581] semaphore — A tempo-word; it governs order, waiting, branching, or repetition. [0582] sequence point — A coordination word; it manages concurrency, interruption, or flow. [0583] serialize access — A time-binding word; it changes when an action may proceed. [0584] signal {Ctrl} — A time-binding word; it changes when an action may proceed. [0585] sleep — A sequencing word; it decides what happens next and under what condition. [0586] spawn {Ctrl} — A sequencing word; it decides what happens next and under what condition. [0587] step — A tempo-word; it governs order, waiting, branching, or repetition. [0588] stop — A time-binding word; it changes when an action may proceed. [0589] suspend — A time-binding word; it changes when an action may proceed. [0590] switch — A time-binding word; it changes when an action may proceed. [0591] sync — A sequencing word; it decides what happens next and under what condition. [0592] synchronize — A tempo-word; it governs order, waiting, branching, or repetition. [0593] task — A coordination word; it manages concurrency, interruption, or flow. [0594] terminate — A sequencing word; it decides what happens next and under what condition. [0595] then — A coordination word; it manages concurrency, interruption, or flow. [0596] throttle — A time-binding word; it changes when an action may proceed. [0597] tick — A coordination word; it manages concurrency, interruption, or flow. [0598] timeout {Ctrl} — Waiting is not free and patience must have a boundary. A timeout is a contract with reality about how long uncertainty is allowed to persist. [0599] timeslice — A coordination word; it manages concurrency, interruption, or flow. [0600] trigger — A tempo-word; it governs order, waiting, branching, or repetition. [0601] try — A coordination word; it manages concurrency, interruption, or flow. [0602] unblock — A time-binding word; it changes when an action may proceed. [0603] until — A tempo-word; it governs order, waiting, branching, or repetition. [0604] wait — A sequencing word; it decides what happens next and under what condition. [0605] wake — A tempo-word; it governs order, waiting, branching, or repetition. [0606] when — A time-binding word; it changes when an action may proceed. [0607] while — A sequencing word; it decides what happens next and under what condition. [0608] yield — A coordination word; it manages concurrency, interruption, or flow. Runtime, Memory, and Execution If a program is a spell in motion, this house describes the vessel that holds the motion. These are embodiment words: where computation resides, how it is allocated, how it is scheduled, and how it is reclaimed. [0609] address space — A vessel-word; it shapes how memory and execution are physically arranged. [0610] aliasing — An embodiment-word; it concerns where computation resides and how it is reclaimed. [0611] allocation — A vessel-word; it shapes how memory and execution are physically arranged. [0612] allocator — A living-system word; it describes the program while it is actually in motion. [0613] arena — A runtime-law word; it constrains performance, allocation, or safety at execution time. [0614] borrow {Run} — A runtime-law word; it constrains performance, allocation, or safety at execution time. [0615] cache {Run} — Keep likely things close so future cost falls. Shadow: stale truth delivered at machine speed. [0616] cache line {Run} — An embodiment-word; it concerns where computation resides and how it is reclaimed. [0617] call frame — A runtime-law word; it constrains performance, allocation, or safety at execution time. [0618] call stack — A vessel-word; it shapes how memory and execution are physically arranged. [0619] closure environment — A vessel-word; it shapes how memory and execution are physically arranged. [0620] compaction {Run} — A living-system word; it describes the program while it is actually in motion. [0621] copy-on-write {Run} — A living-system word; it describes the program while it is actually in motion. [0622] core dump {Run} — A runtime-law word; it constrains performance, allocation, or safety at execution time. [0623] deallocation — A runtime-law word; it constrains performance, allocation, or safety at execution time. [0624] destructor {Run} — A runtime-law word; it constrains performance, allocation, or safety at execution time. [0625] dynamic allocation — A runtime-law word; it constrains performance, allocation, or safety at execution time. [0626] eager evaluation — An embodiment-word; it concerns where computation resides and how it is reclaimed. [0627] escape analysis — A living-system word; it describes the program while it is actually in motion. [0628] execution context — A living-system word; it describes the program while it is actually in motion. [0629] finalizer — An embodiment-word; it concerns where computation resides and how it is reclaimed. [0630] frame pointer — An embodiment-word; it concerns where computation resides and how it is reclaimed. [0631] garbage collection — A reclamation word; unreachable memory is gathered and returned. [0632] generation — An embodiment-word; it concerns where computation resides and how it is reclaimed. [0633] handle {Run} — An embodiment-word; it concerns where computation resides and how it is reclaimed. [0634] heap — A vessel-word; it shapes how memory and execution are physically arranged. [0635] heap object — A living-system word; it describes the program while it is actually in motion. [0636] hot path {Run} — An embodiment-word; it concerns where computation resides and how it is reclaimed. [0637] inline cache — A runtime-law word; it constrains performance, allocation, or safety at execution time. [0638] interpreter loop — A vessel-word; it shapes how memory and execution are physically arranged. [0639] JIT — A just-in-time word; translation happens at runtime rather than earlier in the forge. [0640] layout {Run} — A vessel-word; it shapes how memory and execution are physically arranged. [0641] lazy evaluation — An embodiment-word; it concerns where computation resides and how it is reclaimed. [0642] leak {Run} — A living-system word; it describes the program while it is actually in motion. [0643] lifetime {Run} — A runtime-law word; it constrains performance, allocation, or safety at execution time. [0644] live set — An embodiment-word; it concerns where computation resides and how it is reclaimed. [0645] locality — A living-system word; it describes the program while it is actually in motion. [0646] lock-free {Run} — A progress word; some thread always moves forward without a lock. [0647] mark phase — An embodiment-word; it concerns where computation resides and how it is reclaimed. [0648] memory {Run} — A living-system word; it describes the program while it is actually in motion. [0649] memory barrier — An ordering word; it forbids certain reorderings across threads or hardware boundaries. [0650] memory map — A runtime-law word; it constrains performance, allocation, or safety at execution time. [0651] memory pool — A runtime-law word; it constrains performance, allocation, or safety at execution time. [0652] memory safety — A living-system word; it describes the program while it is actually in motion. [0653] move semantics — A vessel-word; it shapes how memory and execution are physically arranged. [0654] object header — An embodiment-word; it concerns where computation resides and how it is reclaimed. [0655] page {Run} — A living-system word; it describes the program while it is actually in motion. [0656] page fault — A living-system word; it describes the program while it is actually in motion. [0657] pinning — A runtime-law word; it constrains performance, allocation, or safety at execution time. [0658] pointer {Run} — A location word; it does not hold the thing, but where the thing may be found. [0659] pool allocator — A runtime-law word; it constrains performance, allocation, or safety at execution time. [0660] prefetch — A living-system word; it describes the program while it is actually in motion. [0661] quiescence — A living-system word; it describes the program while it is actually in motion. [0662] reclaim — A living-system word; it describes the program while it is actually in motion. [0663] reference count — An embodiment-word; it concerns where computation resides and how it is reclaimed. [0664] register allocation — A runtime-law word; it constrains performance, allocation, or safety at execution time. [0665] root set — An embodiment-word; it concerns where computation resides and how it is reclaimed. [0666] runtime — A living word; the conditions under which the program presently exists and executes. [0667] sandbox {Run} — A confinement word; actions are permitted only within a restricted space. [0668] shadow stack — An embodiment-word; it concerns where computation resides and how it is reclaimed. [0669] slab allocator — A runtime-law word; it constrains performance, allocation, or safety at execution time. [0670] stack {Run} — A layering word; order matters and the most recent thing is nearest the top. [0671] stack frame — A living-system word; it describes the program while it is actually in motion. [0672] stop-the-world — A living-system word; it describes the program while it is actually in motion. [0673] sweep phase — A living-system word; it describes the program while it is actually in motion. [0674] tail call — A vessel-word; it shapes how memory and execution are physically arranged. [0675] thread-local storage — A living-system word; it describes the program while it is actually in motion. [0676] TLB — A vessel-word; it shapes how memory and execution are physically arranged. [0677] tracing collector — A runtime-law word; it constrains performance, allocation, or safety at execution time. [0678] unbox — An embodiment-word; it concerns where computation resides and how it is reclaimed. [0679] user heap — A living-system word; it describes the program while it is actually in motion. [0680] virtual memory — An embodiment-word; it concerns where computation resides and how it is reclaimed. [0681] VM — A runtime-law word; it constrains performance, allocation, or safety at execution time. [0682] wait-free {Run} — An embodiment-word; it concerns where computation resides and how it is reclaimed. [0683] write barrier — A vessel-word; it shapes how memory and execution are physically arranged. [0684] zero-copy {Run} — Data movement stripped down to the minimum number of duplications. Use it when the bottleneck is physical movement rather than arithmetic. ________________

Systems Programming and Operating-System Words These are the host-governing words. They belong to processes, kernels, files, descriptors, interrupts, devices, permissions, and the bargain between user space and machine authority. A great deal of software magic turns on knowing which words in this house are ordinary and which are dangerous. [0685] boot — A host-word; it governs how programs bargain with the operating system. [0686] bootloader — An operating word; it changes how software inhabits the host machine. [0687] capability mode — An operating word; it changes how software inhabits the host machine. [0688] cgroup — A host-word; it governs how programs bargain with the operating system. [0689] chroot — An operating word; it changes how software inhabits the host machine. [0690] context switch — An operating word; it changes how software inhabits the host machine. [0691] cron — A machine-host word; it marks a boundary where software meets system authority. [0692] daemon {Sys} — A host-word; it governs how programs bargain with the operating system. [0693] device — A host-word; it governs how programs bargain with the operating system. [0694] device tree — A host-word; it governs how programs bargain with the operating system. [0695] direct I/O — A machine-host word; it marks a boundary where software meets system authority. [0696] driver — A translation word between software intent and device behavior. [0697] epoll — A host-word; it governs how programs bargain with the operating system. [0698] exec — A kernel-adjacent word; it concerns process, device, file, or privilege. [0699] exit code — A kernel-adjacent word; it concerns process, device, file, or privilege. [0700] file — A host-word; it governs how programs bargain with the operating system. [0701] file descriptor — An operating word; it changes how software inhabits the host machine. [0702] file lock — A kernel-adjacent word; it concerns process, device, file, or privilege. [0703] filesystem — A kernel-adjacent word; it concerns process, device, file, or privilege. [0704] firmware {Sys} — A kernel-adjacent word; it concerns process, device, file, or privilege. [0705] fork {Sys} — A machine-host word; it marks a boundary where software meets system authority. [0706] futex — A host-word; it governs how programs bargain with the operating system. [0707] group id — A machine-host word; it marks a boundary where software meets system authority. [0708] init — A host-word; it governs how programs bargain with the operating system. [0709] inode — An operating word; it changes how software inhabits the host machine. [0710] interrupt — A priority word from the machine; ordinary flow is preempted for urgent handling. [0711] ioctl — An operating word; it changes how software inhabits the host machine. [0712] IRQ — A host-word; it governs how programs bargain with the operating system. [0713] isolate {Sys} — A kernel-adjacent word; it concerns process, device, file, or privilege. [0714] kernel — A sovereignty word; the operating system’s core authority over process, memory, and device. [0715] kernelspace — A kernel-adjacent word; it concerns process, device, file, or privilege. [0716] kill signal — A machine-host word; it marks a boundary where software meets system authority. [0717] link layer device — An operating word; it changes how software inhabits the host machine. [0718] load average — An operating word; it changes how software inhabits the host machine. [0719] login shell — A kernel-adjacent word; it concerns process, device, file, or privilege. [0720] mount — An operating word; it changes how software inhabits the host machine. [0721] namespace {Sys} — A kernel-adjacent word; it concerns process, device, file, or privilege. [0722] niceness — A host-word; it governs how programs bargain with the operating system. [0723] nonblocking I/O — An operating word; it changes how software inhabits the host machine. [0724] open file table — A machine-host word; it marks a boundary where software meets system authority. [0725] page cache — A kernel-adjacent word; it concerns process, device, file, or privilege. [0726] page table — A kernel-adjacent word; it concerns process, device, file, or privilege. [0727] path — A kernel-adjacent word; it concerns process, device, file, or privilege. [0728] permission {Sys} — A kernel-adjacent word; it concerns process, device, file, or privilege. [0729] pipe — A machine-host word; it marks a boundary where software meets system authority. [0730] poll {Sys} — An operating word; it changes how software inhabits the host machine. [0731] privilege — An operating word; it changes how software inhabits the host machine. [0732] process {Sys} — A sovereignty word; an executing program with its own protected address space. [0733] process table — An operating word; it changes how software inhabits the host machine. [0734] pseudo-terminal — A kernel-adjacent word; it concerns process, device, file, or privilege. [0735] pthread — A host-word; it governs how programs bargain with the operating system. [0736] quota — A machine-host word; it marks a boundary where software meets system authority. [0737] read-only mount — A machine-host word; it marks a boundary where software meets system authority. [0738] real-time scheduler — An operating word; it changes how software inhabits the host machine. [0739] run queue — A machine-host word; it marks a boundary where software meets system authority. [0740] scheduler class — A kernel-adjacent word; it concerns process, device, file, or privilege. [0741] select {Sys} — A host-word; it governs how programs bargain with the operating system. [0742] service manager — A host-word; it governs how programs bargain with the operating system. [0743] session leader — A kernel-adjacent word; it concerns process, device, file, or privilege. [0744] shared memory — A host-word; it governs how programs bargain with the operating system. [0745] signal {Sys} — A machine-host word; it marks a boundary where software meets system authority. [0746] socket {Sys} — A conduit word; a live endpoint for network communication. [0747] softirq — A host-word; it governs how programs bargain with the operating system. [0748] spawn {Sys} — A kernel-adjacent word; it concerns process, device, file, or privilege. [0749] standard error — An operating word; it changes how software inhabits the host machine. [0750] standard input — A kernel-adjacent word; it concerns process, device, file, or privilege. [0751] standard output — A machine-host word; it marks a boundary where software meets system authority. [0752] sticky bit — A machine-host word; it marks a boundary where software meets system authority. [0753] stream descriptor — An operating word; it changes how software inhabits the host machine. [0754] swap — An operating word; it changes how software inhabits the host machine. [0755] syscall — An operating word; it changes how software inhabits the host machine. [0756] system call boundary — A kernel-adjacent word; it concerns process, device, file, or privilege. [0757] systemd unit — A kernel-adjacent word; it concerns process, device, file, or privilege. [0758] tempfile — A machine-host word; it marks a boundary where software meets system authority. [0759] terminal — A host-word; it governs how programs bargain with the operating system. [0760] thread — A line-of-execution word that shares process memory with its siblings. [0761] timer — A kernel-adjacent word; it concerns process, device, file, or privilege. [0762] trap — An operating word; it changes how software inhabits the host machine. [0763] tty — A kernel-adjacent word; it concerns process, device, file, or privilege. [0764] umask — A kernel-adjacent word; it concerns process, device, file, or privilege. [0765] unmount — A machine-host word; it marks a boundary where software meets system authority. [0766] user id — A host-word; it governs how programs bargain with the operating system. [0767] userland — A machine-host word; it marks a boundary where software meets system authority. [0768] virtual file system — A host-word; it governs how programs bargain with the operating system. [0769] watchdog — A kernel-adjacent word; it concerns process, device, file, or privilege. [0770] writeback — A host-word; it governs how programs bargain with the operating system. ________________

Networking and Distributed Systems These are distance-bridging words: the terms by which intention travels across machines, packets, failures, retries, and partial knowledge. In distributed work, the same word often carries far more force than it seems to on first reading. Replica, quorum, lease, and idempotent are not decorative vocabulary; they are reality-management terms. [0771] accept — A distance-word; it carries intention across boundaries and unreliable space. [0772] acknowledgment — A distributed-systems word; it manages failure, ordering, or reachability across nodes. [0773] anycast — A distributed-systems word; it manages failure, ordering, or reachability across nodes. [0774] API request — A distributed-systems word; it manages failure, ordering, or reachability across nodes. [0775] API response — A packet-and-possibility word; it matters because the other side may be absent, slow, or stale. [0776] availability zone — A distributed-systems word; it manages failure, ordering, or reachability across nodes. [0777] backoff {Net} — A distance-word; it carries intention across boundaries and unreliable space. [0778] backpressure — Resistance pushed upstream when demand outruns capacity. Without it, overload spreads faster than truth. [0779] bandwidth {Net} — A packet-and-possibility word; it matters because the other side may be absent, slow, or stale. [0780] bind — A fastening word; it joins a name, port, address, or variable to a concrete referent. [0781] broadcast — A distributed-systems word; it manages failure, ordering, or reachability across nodes. [0782] broker {Net} — A packet-and-possibility word; it matters because the other side may be absent, slow, or stale. [0783] CDN — A packet-and-possibility word; it matters because the other side may be absent, slow, or stale. [0784] certificate {Net} — A delegated-trust word; it lets one party assert another’s identity by signed authority. [0785] checksum handoff — A packet-and-possibility word; it matters because the other side may be absent, slow, or stale. [0786] client {Net} — A distributed-systems word; it manages failure, ordering, or reachability across nodes. [0787] client timeout — A many-machine word; it coordinates transport, routing, or agreement beyond one process. [0788] cluster {Net} — A many-body word; several machines are treated as one operational unit. [0789] connect — A many-machine word; it coordinates transport, routing, or agreement beyond one process. [0790] connection pool — A many-machine word; it coordinates transport, routing, or agreement beyond one process. [0791] consensus — A many-machine law-word; it creates shared order without a single unquestioned body. [0792] consistency level — A many-machine word; it coordinates transport, routing, or agreement beyond one process. [0793] control plane {Net} — A packet-and-possibility word; it matters because the other side may be absent, slow, or stale. [0794] CRC — A distance-word; it carries intention across boundaries and unreliable space. [0795] datagram — A packet-and-possibility word; it matters because the other side may be absent, slow, or stale. [0796] deadline — A many-machine word; it coordinates transport, routing, or agreement beyond one process. [0797] destination — A many-machine word; it coordinates transport, routing, or agreement beyond one process. [0798] discovery — A distance-word; it carries intention across boundaries and unreliable space. [0799] DNS — A packet-and-possibility word; it matters because the other side may be absent, slow, or stale. [0800] DNS record — A distance-word; it carries intention across boundaries and unreliable space. [0801] edge {Net} — A packet-and-possibility word; it matters because the other side may be absent, slow, or stale. [0802] egress — A packet-and-possibility word; it matters because the other side may be absent, slow, or stale. [0803] election — A distributed-systems word; it manages failure, ordering, or reachability across nodes. [0804] endpoint — A packet-and-possibility word; it matters because the other side may be absent, slow, or stale. [0805] eventual consistency — Agreement postponed rather than denied. Shadow: stale reads treated as if they were fresh truth. [0806] failover — A continuity word; authority or traffic moves when the current holder fails. [0807] fan-out {Net} — A many-machine word; it coordinates transport, routing, or agreement beyond one process. [0808] firewall — A many-machine word; it coordinates transport, routing, or agreement beyond one process. [0809] follower — A many-machine word; it coordinates transport, routing, or agreement beyond one process. [0810] forwarding — A distributed-systems word; it manages failure, ordering, or reachability across nodes. [0811] frame {Net} — A distributed-systems word; it manages failure, ordering, or reachability across nodes. [0812] gateway {Net} — A many-machine word; it coordinates transport, routing, or agreement beyond one process. [0813] gossip — A rumor-propagation word; state spreads by repeated local exchange. [0814] gRPC — A distance-word; it carries intention across boundaries and unreliable space. [0815] handshake — A mutual-recognition word used to establish parameters, trust, or shared readiness. [0816] health check — A distance-word; it carries intention across boundaries and unreliable space. [0817] heartbeat {Net} — A distance-word; it carries intention across boundaries and unreliable space. [0818] hop — A distributed-systems word; it manages failure, ordering, or reachability across nodes. [0819] HTTP — A distance-word; it carries intention across boundaries and unreliable space. [0820] HTTPS — A distributed-systems word; it manages failure, ordering, or reachability across nodes. [0821] idempotency key — A many-machine word; it coordinates transport, routing, or agreement beyond one process. [0822] ingress — A distributed-systems word; it manages failure, ordering, or reachability across nodes. [0823] jitter {Net} — A timing-noise word; repeated operations arrive with unstable spacing. [0824] keepalive — A many-machine word; it coordinates transport, routing, or agreement beyond one process. [0825] latency — The delay before useful work reaches the caller. Latency is what users feel even when throughput graphs look flattering. [0826] leader — A packet-and-possibility word; it matters because the other side may be absent, slow, or stale. [0827] lease — A temporary-authority word; a resource is held only for a bounded duration. [0828] load balancer — A distance-word; it carries intention across boundaries and unreliable space. [0829] loss — A packet-and-possibility word; it matters because the other side may be absent, slow, or stale. [0830] mailbox — A distance-word; it carries intention across boundaries and unreliable space. [0831] membership — A distance-word; it carries intention across boundaries and unreliable space. [0832] mesh {Net} — A packet-and-possibility word; it matters because the other side may be absent, slow, or stale. [0833] message queue — A many-machine word; it coordinates transport, routing, or agreement beyond one process. [0834] mTLS {Net} — A distance-word; it carries intention across boundaries and unreliable space. [0835] multicast — A many-machine word; it coordinates transport, routing, or agreement beyond one process. [0836] NAT — A distributed-systems word; it manages failure, ordering, or reachability across nodes. [0837] network partition — A distance-word; it carries intention across boundaries and unreliable space. [0838] node {Net} — A many-machine word; it coordinates transport, routing, or agreement beyond one process. [0839] origin — A distance-word; it carries intention across boundaries and unreliable space. [0840] packet — A distance-word; it carries intention across boundaries and unreliable space. [0841] packet loss {Net} — A packet-and-possibility word; it matters because the other side may be absent, slow, or stale. [0842] peer — A distance-word; it carries intention across boundaries and unreliable space. [0843] pipeline depth — A distributed-systems word; it manages failure, ordering, or reachability across nodes. [0844] port {Net} — A contact word; a defined point of communication or adaptation. [0845] proxy {Net} — A stand-in word; one body speaks or receives on behalf of another. [0846] publish-subscribe — A many-machine word; it coordinates transport, routing, or agreement beyond one process. [0847] QUIC — A many-machine word; it coordinates transport, routing, or agreement beyond one process. [0848] quorum — Not everyone must agree, but enough must. This word turns distributed action into a threshold question instead of a unanimous fantasy. [0849] rate limit — A distributed-systems word; it manages failure, ordering, or reachability across nodes. [0850] receiver window — A packet-and-possibility word; it matters because the other side may be absent, slow, or stale. [0851] redirect — A many-machine word; it coordinates transport, routing, or agreement beyond one process. [0852] replica — A mirroring word; state is maintained in more than one place. [0853] replication — A many-machine word; it coordinates transport, routing, or agreement beyond one process. [0854] request — A packet-and-possibility word; it matters because the other side may be absent, slow, or stale. [0855] request coalescing — A packet-and-possibility word; it matters because the other side may be absent, slow, or stale. [0856] response — A returning word; the answer carried back across an invoked boundary. [0857] retry {Net} — A second-attempt word; failure does not end the ritual if policy allows another try. [0858] reverse proxy — A many-machine word; it coordinates transport, routing, or agreement beyond one process. [0859] route — A path word; messages or requests are sent by a chosen way rather than all ways. [0860] router {Net} — A packet-and-possibility word; it matters because the other side may be absent, slow, or stale. [0861] routing table — A distance-word; it carries intention across boundaries and unreliable space. [0862] RPC — A packet-and-possibility word; it matters because the other side may be absent, slow, or stale. [0863] segment {Net} — A distributed-systems word; it manages failure, ordering, or reachability across nodes. [0864] sequence number — A many-machine word; it coordinates transport, routing, or agreement beyond one process. [0865] service discovery — A packet-and-possibility word; it matters because the other side may be absent, slow, or stale. [0866] service mesh {Net} — A side-channel governance word for service-to-service traffic. [0867] shard {Net} — A splitting word; one logical body is divided across multiple partitions. [0868] sidecar — A distributed-systems word; it manages failure, ordering, or reachability across nodes. [0869] sliding window — A many-machine word; it coordinates transport, routing, or agreement beyond one process. [0870] socket {Net} — A conduit word; a live endpoint for network communication. [0871] source — A packet-and-possibility word; it matters because the other side may be absent, slow, or stale. [0872] split-brain {Net} — A packet-and-possibility word; it matters because the other side may be absent, slow, or stale. [0873] stream {Net} — A flow word; values arrive over time rather than all at once. [0874] strong consistency — A sameness word across distance; readers do not see old worlds after new ones commit. [0875] subscription — A packet-and-possibility word; it matters because the other side may be absent, slow, or stale. [0876] TCP — A distributed-systems word; it manages failure, ordering, or reachability across nodes. [0877] timeout {Net} — A patience-bound word; after a duration, waiting is no longer allowed. [0878] TLS — A distributed-systems word; it manages failure, ordering, or reachability across nodes. [0879] topic — A distributed-systems word; it manages failure, ordering, or reachability across nodes. [0880] tracing header — A packet-and-possibility word; it matters because the other side may be absent, slow, or stale. [0881] UDP — A packet-and-possibility word; it matters because the other side may be absent, slow, or stale. [0882] unicast — A distributed-systems word; it manages failure, ordering, or reachability across nodes. [0883] virtual IP — A distance-word; it carries intention across boundaries and unreliable space. [0884] webhook — A distributed-systems word; it manages failure, ordering, or reachability across nodes. [0885] WebSocket — A distributed-systems word; it manages failure, ordering, or reachability across nodes. [0886] wire format — A distance-word; it carries intention across boundaries and unreliable space. ________________

Databases, Persistence, and Time-Binding Words Persistence words bind state to time. They matter because software does not merely compute; it remembers. This house contains storage forms, access patterns, transactional laws, and the vocabulary of durable change. [0887] ACID — A storage-law word; it governs how facts are kept, found, or rolled back. [0888] append-only log — A storage-law word; it governs how facts are kept, found, or rolled back. [0889] archive table — A durable-state word; it matters because the system must remember through change. [0890] audit trail — A query-and-history word; it shapes how stored truth is accessed or preserved. [0891] B-tree — A query-and-history word; it shapes how stored truth is accessed or preserved. [0892] backup — A durable-state word; it matters because the system must remember through change. [0893] base table — A query-and-history word; it shapes how stored truth is accessed or preserved. [0894] bitmap index — A storage-law word; it governs how facts are kept, found, or rolled back. [0895] checkpoint — A persistence-word; it binds state to time and query. [0896] column {DB} — A durable-state word; it matters because the system must remember through change. [0897] column store — A query-and-history word; it shapes how stored truth is accessed or preserved. [0898] commit {DB} — The moment a proposed change becomes durable history. Shadow: writing too early, before the world is actually ready to carry the new truth. [0899] compaction {DB} — A storage-law word; it governs how facts are kept, found, or rolled back. [0900] conflict — A durable-state word; it matters because the system must remember through change. [0901] constraint {DB} — A bounding word; it removes degrees of freedom in order to improve correctness. [0902] covering index — A storage-law word; it governs how facts are kept, found, or rolled back. [0903] cursor {DB} — A durable-state word; it matters because the system must remember through change. [0904] data lake — A query-and-history word; it shapes how stored truth is accessed or preserved. [0905] data warehouse — A storage-law word; it governs how facts are kept, found, or rolled back. [0906] database — A storage-law word; it governs how facts are kept, found, or rolled back. [0907] deadlock {DB} — A binding curse; multiple actors wait on one another forever. [0908] denormalization — A persistence-word; it binds state to time and query. [0909] dimension table — A durable-state word; it matters because the system must remember through change. [0910] durability — A storage-law word; it governs how facts are kept, found, or rolled back. [0911] durable log — A storage-law word; it governs how facts are kept, found, or rolled back. [0912] entity table — A storage-law word; it governs how facts are kept, found, or rolled back. [0913] event store — A query-and-history word; it shapes how stored truth is accessed or preserved. [0914] fact table — A durable-state word; it matters because the system must remember through change. [0915] failover replica — A persistence-word; it binds state to time and query. [0916] foreign key — A query-and-history word; it shapes how stored truth is accessed or preserved. [0917] full table scan — A persistence-word; it binds state to time and query. [0918] index {DB} — A retrieval word; it makes later access faster by storing an alternate path to data. [0919] index hint — A query-and-history word; it shapes how stored truth is accessed or preserved. [0920] index seek — A persistence-word; it binds state to time and query. [0921] isolation level — A durable-state word; it matters because the system must remember through change. [0922] join {DB} — A union word; separate streams, sets, or histories are brought into one result. [0923] keyspace — A storage-law word; it governs how facts are kept, found, or rolled back. [0924] LSM tree — A persistence-word; it binds state to time and query. [0925] materialized view — A durable-state word; it matters because the system must remember through change. [0926] migration — Stored reality changing shape without being lost. Good migrations are staged, inspectable, and reversible long enough to discover what the data actually contains. [0927] MVCC — A storage-law word; it governs how facts are kept, found, or rolled back. [0928] nonclustered index — A durable-state word; it matters because the system must remember through change. [0929] OLAP — A persistence-word; it binds state to time and query. [0930] OLTP — A query-and-history word; it shapes how stored truth is accessed or preserved. [0931] partition {DB} — A durable-state word; it matters because the system must remember through change. [0932] partition key — A query-and-history word; it shapes how stored truth is accessed or preserved. [0933] primary key — A storage-law word; it governs how facts are kept, found, or rolled back. [0934] query plan — A storage-law word; it governs how facts are kept, found, or rolled back. [0935] read committed — A durable-state word; it matters because the system must remember through change. [0936] read replica — A persistence-word; it binds state to time and query. [0937] record lock — A persistence-word; it binds state to time and query. [0938] redo log — A persistence-word; it binds state to time and query. [0939] relation {DB} — A durable-state word; it matters because the system must remember through change. [0940] repeatable read — A storage-law word; it governs how facts are kept, found, or rolled back. [0941] replication lag — A durable-state word; it matters because the system must remember through change. [0942] retention — A persistence-word; it binds state to time and query. [0943] rollback {DB} — Permission to retreat toward a previously trusted state. A system without rollback mistakes hope for safety. [0944] row {DB} — A persistence-word; it binds state to time and query. [0945] row store — A storage-law word; it governs how facts are kept, found, or rolled back. [0946] savepoint — A storage-law word; it governs how facts are kept, found, or rolled back. [0947] scan {DB} — A storage-law word; it governs how facts are kept, found, or rolled back. [0948] schema {DB} — A shape word for stored meaning. [0949] secondary index — A persistence-word; it binds state to time and query. [0950] seed data — A query-and-history word; it shapes how stored truth is accessed or preserved. [0951] serializable {DB} — A query-and-history word; it shapes how stored truth is accessed or preserved. [0952] sharding — A persistence-word; it binds state to time and query. [0953] snapshot isolation — A durable-state word; it matters because the system must remember through change. [0954] sort key — A storage-law word; it governs how facts are kept, found, or rolled back. [0955] stored procedure — A durable-state word; it matters because the system must remember through change. [0956] table {DB} — A persistence-word; it binds state to time and query. [0957] table scan — A storage-law word; it governs how facts are kept, found, or rolled back. [0958] tenant isolation — A persistence-word; it binds state to time and query. [0959] transaction — An all-or-nothing persistence word. [0960] TTL — A persistence-word; it binds state to time and query. [0961] tuple {DB} — A durable-state word; it matters because the system must remember through change. [0962] unique constraint — A persistence-word; it binds state to time and query. [0963] upsert — A query-and-history word; it shapes how stored truth is accessed or preserved. [0964] vacuum — A storage-law word; it governs how facts are kept, found, or rolled back. [0965] view {DB} — A query-and-history word; it shapes how stored truth is accessed or preserved. [0966] WAL — A persistence-word; it binds state to time and query. [0967] warehouse model — A persistence-word; it binds state to time and query. [0968] write skew {DB} — A storage-law word; it governs how facts are kept, found, or rolled back. ________________

Security, Trust, and Warding Words These are ward words: the vocabulary of secrecy, identity, authority, integrity, and controlled access. Security words are unusually magical because they often sound ordinary while carrying severe consequences. A bad interface can be ugly. A bad trust boundary can be catastrophic. [0969] ABAC — A defense word; it shapes how systems resist misuse, theft, or forgery. [0970] access control — A defense word; it shapes how systems resist misuse, theft, or forgery. [0971] account — A threshold word; it governs who may enter, know, or act. [0972] ACL — A ward-word; it protects trust, secrecy, or authority. [0973] allowlist — A defense word; it shapes how systems resist misuse, theft, or forgery. [0974] attestation — A proof that a thing is what it claims to be or was produced the way it claims. It matters most when trust cannot be assumed. [0975] audit — A defense word; it shapes how systems resist misuse, theft, or forgery. [0976] authenticate — Prove who is making the claim before deciding what the claimant may do. Shadow: trusting names that have not earned entrance. [0977] authentication — A ward-word; it protects trust, secrecy, or authority. [0978] authorization — After identity is known, what acts are permitted? Shadow: accidental omnipotence hidden behind a successful login. [0979] availability — A promise word that says the system can still be reached when called upon. [0980] bearer token — A trust-boundary word; it matters because compromise often hides inside ordinary-looking names. [0981] blast radius — A trust-boundary word; it matters because compromise often hides inside ordinary-looking names. [0982] blocklist — A defense word; it shapes how systems resist misuse, theft, or forgery. [0983] boundary defense — A trust-boundary word; it matters because compromise often hides inside ordinary-looking names. [0984] capability {Sec} — A trust-boundary word; it matters because compromise often hides inside ordinary-looking names. [0985] certificate {Sec} — A delegated-trust word; it lets one party assert another’s identity by signed authority. [0986] challenge — A defense word; it shapes how systems resist misuse, theft, or forgery. [0987] cipher — A defense word; it shapes how systems resist misuse, theft, or forgery. [0988] claim — A trust-boundary word; it matters because compromise often hides inside ordinary-looking names. [0989] client secret — A threshold word; it governs who may enter, know, or act. [0990] code signing — A trust-boundary word; it matters because compromise often hides inside ordinary-looking names. [0991] compliance — A defense word; it shapes how systems resist misuse, theft, or forgery. [0992] confidentiality — A trust-boundary word; it matters because compromise often hides inside ordinary-looking names. [0993] credential {Sec} — A defense word; it shapes how systems resist misuse, theft, or forgery. [0994] cross-site scripting — A defense word; it shapes how systems resist misuse, theft, or forgery. [0995] cryptographic nonce — A trust-boundary word; it matters because compromise often hides inside ordinary-looking names. [0996] CSRF — A trust-boundary word; it matters because compromise often hides inside ordinary-looking names. [0997] decrypt {Sec} — An unsealing word; protected meaning becomes legible again under the right key. [0998] defense in depth — A trust-boundary word; it matters because compromise often hides inside ordinary-looking names. [0999] deny-by-default — A trust-boundary word; it matters because compromise often hides inside ordinary-looking names. [1000] digest {Sec} — A ward-word; it protects trust, secrecy, or authority. [1001] enclave — A trust-boundary word; it matters because compromise often hides inside ordinary-looking names. [1002] encrypt {Sec} — A warding word; it hides meaning from everyone except the right holder of the key. [1003] entropy — A threshold word; it governs who may enter, know, or act. [1004] exfiltration — A threshold word; it governs who may enter, know, or act. [1005] exploit — A threshold word; it governs who may enter, know, or act. [1006] harden — A trust-boundary word; it matters because compromise often hides inside ordinary-looking names. [1007] hash {Sec} — Arbitrary input reduced to a fixed fingerprint. Use it for identity, integrity, bucketing, and change detection; never mistake it for secrecy. [1008] HMAC — A threshold word; it governs who may enter, know, or act. [1009] identity — A trust-boundary word; it matters because compromise often hides inside ordinary-looking names. [1010] incident — A trust-boundary word; it matters because compromise often hides inside ordinary-looking names. [1011] injection — A defense word; it shapes how systems resist misuse, theft, or forgery. [1012] integrity — A defense word; it shapes how systems resist misuse, theft, or forgery. [1013] isolate {Sec} — A threshold word; it governs who may enter, know, or act. [1014] key {Sec} — A threshold word; it governs who may enter, know, or act. [1015] key exchange — A ward-word; it protects trust, secrecy, or authority. [1016] key rotation — A threshold word; it governs who may enter, know, or act. [1017] least privilege — Give only the authority required for the present act, no more. It is one of the simplest words for reducing future regret. [1018] login — A threshold word; it governs who may enter, know, or act. [1019] mTLS {Sec} — A ward-word; it protects trust, secrecy, or authority. [1020] mutual authentication — A ward-word; it protects trust, secrecy, or authority. [1021] nonce — A defense word; it shapes how systems resist misuse, theft, or forgery. [1022] passkey — A ward-word; it protects trust, secrecy, or authority. [1023] password — A defense word; it shapes how systems resist misuse, theft, or forgery. [1024] patch {Sec} — A repair word; a bounded alteration is applied to an existing body. [1025] pepper — A ward-word; it protects trust, secrecy, or authority. [1026] permission {Sec} — A threshold word; it governs who may enter, know, or act. [1027] phishing — A trust-boundary word; it matters because compromise often hides inside ordinary-looking names. [1028] policy — The declared rule by which a class of cases is decided. Good policy reduces arbitrary judgment; bad policy merely freezes confusion. [1029] principal — A trust-boundary word; it matters because compromise often hides inside ordinary-looking names. [1030] private key — A ward-word; it protects trust, secrecy, or authority. [1031] privilege escalation — A trust-boundary word; it matters because compromise often hides inside ordinary-looking names. [1032] proof of possession — A threshold word; it governs who may enter, know, or act. [1033] public key — A ward-word; it protects trust, secrecy, or authority. [1034] quarantine — A ward-word; it protects trust, secrecy, or authority. [1035] rate limiting — A threshold word; it governs who may enter, know, or act. [1036] replay attack — A threshold word; it governs who may enter, know, or act. [1037] revocation — A trust-boundary word; it matters because compromise often hides inside ordinary-looking names. [1038] role {Sec} — An invocation word; it frames what kind of actor the model should pretend to be. [1039] root of trust — A defense word; it shapes how systems resist misuse, theft, or forgery. [1040] rotate — A defense word; it shapes how systems resist misuse, theft, or forgery. [1041] salt — A ward-word; it protects trust, secrecy, or authority. [1042] sandbox {Sec} — A confinement word; actions are permitted only within a restricted space. [1043] scope {Sec} — A trust-boundary word; it matters because compromise often hides inside ordinary-looking names. [1044] secret {Sec} — A guarded-value word meant to remain hidden except to the few who must know it. [1045] secure enclave — A threshold word; it governs who may enter, know, or act. [1046] security boundary — A ward-word; it protects trust, secrecy, or authority. [1047] session fixation — A trust-boundary word; it matters because compromise often hides inside ordinary-looking names. [1048] session token — A threshold word; it governs who may enter, know, or act. [1049] sign {Sec} — A sealing word; origin or integrity is bound cryptographically to content. [1050] signature {Sec} — Identity or intent made checkable through cryptographic proof. Useful wherever trust must survive distance and replay. [1051] single sign-on — A threshold word; it governs who may enter, know, or act. [1052] spoofing — A threshold word; it governs who may enter, know, or act. [1053] SSRF — A trust-boundary word; it matters because compromise often hides inside ordinary-looking names. [1054] threat model — A threshold word; it governs who may enter, know, or act. [1055] token {Sec} — A countable unit of text or symbol used for parsing, modeling, or encoding. [1056] trust anchor — A threshold word; it governs who may enter, know, or act. [1057] trust boundary — A trust-boundary word; it matters because compromise often hides inside ordinary-looking names. [1058] validate {Sec} — A gatekeeping word; inputs or outputs are checked against an expected form. [1059] verification {Sec} — A truth-checking word that asks not merely for output, but for justified output. [1060] vulnerability — A trust-boundary word; it matters because compromise often hides inside ordinary-looking names. [1061] ward — A trust-boundary word; it matters because compromise often hides inside ordinary-looking names. [1062] webhook signing — A trust-boundary word; it matters because compromise often hides inside ordinary-looking names. [1063] zero trust — A trust-boundary word; it matters because compromise often hides inside ordinary-looking names. ________________

Build, Tooling, Versioning, and Release This is the forge house. Its words turn source into artifacts, artifacts into releases, and releases into maintained history. Many software organizations run almost entirely on the ritual power of words in this house: build, branch, merge, deploy, rollback, tag, release. [1064] artifact — A history-and-release word; it determines how change is packaged and remembered. [1065] assemble {Forge} — A forge-word; it turns work into artifact, revision, or release. [1066] baseline {Forge} — A workshop word; it shapes the rituals by which teams produce running systems. [1067] binary — A delivery word; it moves software through build, review, and deployment. [1068] branch {Forge} — A divergence word; execution or history splits into alternate paths. [1069] build — A forge word; it turns source into artifact. [1070] build cache — A forge-word; it turns work into artifact, revision, or release. [1071] build graph — A history-and-release word; it determines how change is packaged and remembered. [1072] bundle — A history-and-release word; it determines how change is packaged and remembered. [1073] canary — A deliberately limited release whose job is to discover whether production reality agrees with the story told in staging. [1074] changelog — A forge-word; it turns work into artifact, revision, or release. [1075] cherry-pick — A delivery word; it moves software through build, review, and deployment. [1076] CI — A forge-word; it turns work into artifact, revision, or release. [1077] codegen — A delivery word; it moves software through build, review, and deployment. [1078] commit {Forge} — A sealing word; it makes a change part of durable history. [1079] compile {Forge} — A transmutation word; it transforms one language into another fit for execution. [1080] container {Forge} — A workshop word; it shapes the rituals by which teams produce running systems. [1081] container image — A history-and-release word; it determines how change is packaged and remembered. [1082] continuous delivery — A workshop word; it shapes the rituals by which teams produce running systems. [1083] continuous integration — A workshop word; it shapes the rituals by which teams produce running systems. [1084] dependency — A workshop word; it shapes the rituals by which teams produce running systems. [1085] dependency graph — A delivery word; it moves software through build, review, and deployment. [1086] deploy — The crossing from forge to world. Many good ideas become bad facts only after they are actually shipped. [1087] deployment ring — A delivery word; it moves software through build, review, and deployment. [1088] diff {Forge} — A visible account of what changed between one state and another. Good diffs make review local; bad diffs turn truth into fog. [1089] distribution — A forge-word; it turns work into artifact, revision, or release. [1090] Dockerfile — A forge-word; it turns work into artifact, revision, or release. [1091] downgrade — A workshop word; it shapes the rituals by which teams produce running systems. [1092] environment — A delivery word; it moves software through build, review, and deployment. [1093] feature flag — A history-and-release word; it determines how change is packaged and remembered. [1094] formatter — A forge-word; it turns work into artifact, revision, or release. [1095] hermetic build — A delivery word; it moves software through build, review, and deployment. [1096] install — A workshop word; it shapes the rituals by which teams produce running systems. [1097] installer — A history-and-release word; it determines how change is packaged and remembered. [1098] issue tracker — A delivery word; it moves software through build, review, and deployment. [1099] job runner — A delivery word; it moves software through build, review, and deployment. [1100] label {Forge} — A forge-word; it turns work into artifact, revision, or release. [1101] lint — A workshop word; it shapes the rituals by which teams produce running systems. [1102] lockfile — A delivery word; it moves software through build, review, and deployment. [1103] manifest — A workshop word; it shapes the rituals by which teams produce running systems. [1104] merge {Forge} — A reconciliation word; separate lines of change are brought back together. [1105] migration script — A workshop word; it shapes the rituals by which teams produce running systems. [1106] minifier — A workshop word; it shapes the rituals by which teams produce running systems. [1107] package {Forge} — A forge-word; it turns work into artifact, revision, or release. [1108] package manager — A workshop word; it shapes the rituals by which teams produce running systems. [1109] patch release — A delivery word; it moves software through build, review, and deployment. [1110] pin — A workshop word; it shapes the rituals by which teams produce running systems. [1111] pipeline {Forge} — A procession word; work passes through ordered stages. [1112] precommit hook — A delivery word; it moves software through build, review, and deployment. [1113] preview environment — A workshop word; it shapes the rituals by which teams produce running systems. [1114] promote — A history-and-release word; it determines how change is packaged and remembered. [1115] publish — A workshop word; it shapes the rituals by which teams produce running systems. [1116] rebase — A history-and-release word; it determines how change is packaged and remembered. [1117] release — A delivery word; it moves software through build, review, and deployment. [1118] release candidate — A history-and-release word; it determines how change is packaged and remembered. [1119] repository {Forge} — A custody word; an official place from which versions or entities are retrieved. [1120] reproducible build — A forge-word; it turns work into artifact, revision, or release. [1121] restore {Forge} — A forge-word; it turns work into artifact, revision, or release. [1122] revision {Forge} — A workshop word; it shapes the rituals by which teams produce running systems. [1123] rollback {Forge} — A reversal word; the system returns toward an earlier trusted state. [1124] rollout — A delivery word; it moves software through build, review, and deployment. [1125] scaffold {Forge} — A history-and-release word; it determines how change is packaged and remembered. [1126] semantic version — A history-and-release word; it determines how change is packaged and remembered. [1127] ship — A forge-word; it turns work into artifact, revision, or release. [1128] source map — A workshop word; it shapes the rituals by which teams produce running systems. [1129] staging — A delivery word; it moves software through build, review, and deployment. [1130] static analysis — A forge-word; it turns work into artifact, revision, or release. [1131] tag — A forge-word; it turns work into artifact, revision, or release. [1132] template {Forge} — A forge-word; it turns work into artifact, revision, or release. [1133] test gate — A delivery word; it moves software through build, review, and deployment. [1134] toolchain — A delivery word; it moves software through build, review, and deployment. [1135] transitive dependency — A forge-word; it turns work into artifact, revision, or release. [1136] upgrade — A forge-word; it turns work into artifact, revision, or release. [1137] version — A chronology word; the same thing is named at different moments. [1138] version pin — A delivery word; it moves software through build, review, and deployment. [1139] workspace — A workshop word; it shapes the rituals by which teams produce running systems. ________________

Testing, Verification, and Observability These are proving words and revelation words. Some ask whether a claim is true; others expose hidden state so that truth can be checked. Together they form the discipline by which software becomes not just built, but known. [1140] acceptance test — A truth-seeking word; it narrows the gap between what is believed and what is known. [1141] alert — A proving-word; it asks whether a claim is actually true. [1142] assertion {Proof} — A proving-word; it asks whether a claim is actually true. [1143] audit log — A revelation word; it exposes hidden state so a claim can be checked. [1144] backtrace — A proving-word; it asks whether a claim is actually true. [1145] baseline {Proof} — A truth-seeking word; it narrows the gap between what is believed and what is known. [1146] benchmark — A performance claim forced to meet measurement. Benchmarks are where speed rhetoric either cashes out or dies. [1147] black-box test — A truth-seeking word; it narrows the gap between what is believed and what is known. [1148] canary check — A proving-word; it asks whether a claim is actually true. [1149] check — A discipline word; it converts intuition into measurable evidence. [1150] code coverage — A truth-seeking word; it narrows the gap between what is believed and what is known. [1151] conformance — A truth-seeking word; it narrows the gap between what is believed and what is known. [1152] contract test — A promise checked at the seam between systems. Use it when mocks are too flattering and end-to-end tests are too blunt. [1153] core dump {Proof} — A truth-seeking word; it narrows the gap between what is believed and what is known. [1154] counter {Proof} — A proving-word; it asks whether a claim is actually true. [1155] dashboard — A proving-word; it asks whether a claim is actually true. [1156] debugger — A seeing word; it arrests motion so hidden state may be inspected. [1157] diagnostic — A revelation word; it exposes hidden state so a claim can be checked. [1158] error budget — A revelation word; it exposes hidden state so a claim can be checked. [1159] evaluation {Proof} — A proving-word; it asks whether a claim is actually true. [1160] expectation — A proving-word; it asks whether a claim is actually true. [1161] fixture — A truth-seeking word; it narrows the gap between what is believed and what is known. [1162] flame graph — A truth-seeking word; it narrows the gap between what is believed and what is known. [1163] fuzzing — A revelation word; it exposes hidden state so a claim can be checked. [1164] gauge — A revelation word; it exposes hidden state so a claim can be checked. [1165] golden test — A revelation word; it exposes hidden state so a claim can be checked. [1166] harness — A proving-word; it asks whether a claim is actually true. [1167] health probe — A discipline word; it converts intuition into measurable evidence. [1168] histogram — A discipline word; it converts intuition into measurable evidence. [1169] hypothesis — A proving-word; it asks whether a claim is actually true. [1170] incident report — A discipline word; it converts intuition into measurable evidence. [1171] integration test — A proving-word; it asks whether a claim is actually true. [1172] invariant — A law that must remain true while the rest of the system is allowed to move. If you cannot say the invariant, you probably do not yet understand the change. [1173] load test — A proving-word; it asks whether a claim is actually true. [1174] log — A remembrance word; events are written so that they may be later inspected or replayed. [1175] logger — A proving-word; it asks whether a claim is actually true. [1176] metric — A proving-word; it asks whether a claim is actually true. [1177] mock — A discipline word; it converts intuition into measurable evidence. [1178] model check — A truth-seeking word; it narrows the gap between what is believed and what is known. [1179] monitor — A proving-word; it asks whether a claim is actually true. [1180] observability — Enough internal evidence exists that you can infer what the system is doing from the outside. Not logs alone: legible state under pressure. [1181] oracle — A discipline word; it converts intuition into measurable evidence. [1182] postcondition — A revelation word; it exposes hidden state so a claim can be checked. [1183] precondition — A discipline word; it converts intuition into measurable evidence. [1184] profiler — A truth-seeking word; it narrows the gap between what is believed and what is known. [1185] proof — A discipline word; it converts intuition into measurable evidence. [1186] property-based test — Instead of checking one remembered example, ask whether a law survives many generated cases. Use it when you care more about the invariant than the anecdote. [1187] regression test — A revelation word; it exposes hidden state so a claim can be checked. [1188] replay — A revelation word; it exposes hidden state so a claim can be checked. [1189] sampling — A truth-seeking word; it narrows the gap between what is believed and what is known. [1190] sanity check — A discipline word; it converts intuition into measurable evidence. [1191] simulation — A revelation word; it exposes hidden state so a claim can be checked. [1192] smoke test — A truth-seeking word; it narrows the gap between what is believed and what is known. [1193] snapshot test — A proving-word; it asks whether a claim is actually true. [1194] soak test — A discipline word; it converts intuition into measurable evidence. [1195] solver — A truth-seeking word; it narrows the gap between what is believed and what is known. [1196] span — A discipline word; it converts intuition into measurable evidence. [1197] stack trace — A revelation word; it exposes hidden state so a claim can be checked. [1198] static checker — A revelation word; it exposes hidden state so a claim can be checked. [1199] stress test — A proving-word; it asks whether a claim is actually true. [1200] stub — A discipline word; it converts intuition into measurable evidence. [1201] symbolic execution — A discipline word; it converts intuition into measurable evidence. [1202] telemetry — Measurements leaving the system in a form other systems can compare, store, and alert on. Shadow: metric exhaust without explanatory power. [1203] theorem {Proof} — A proving-word; it asks whether a claim is actually true. [1204] trace {Proof} — A preserved path through execution. Use it when the question is not only what failed, but where the causal thread first bent. [1205] tracer — A revelation word; it exposes hidden state so a claim can be checked. [1206] triage — A proving-word; it asks whether a claim is actually true. [1207] unit test — A proving-word; it asks whether a claim is actually true. [1208] validation — A truth-seeking word; it narrows the gap between what is believed and what is known. [1209] verifier — A proving-word; it asks whether a claim is actually true. [1210] white-box test — A truth-seeking word; it narrows the gap between what is believed and what is known. ________________

Hardware, Embedded, and Performance-Near Words This house touches metal, timing, heat, buses, power, and the physical limits beneath abstraction. It includes words that software engineers invoke when they want software to press directly against hardware or when performance itself becomes the governing law. [1211] accelerator — A near-metal word; it matters when abstraction is no longer cheap enough. [1212] alignment {HW} — An embodiment word; software here speaks almost directly to silicon or wire. [1213] ASIC — A machine-word; it reaches into clocks, buses, registers, or heat. [1214] assembly instruction — A performance-and-physics word; it governs timing, placement, and finite material limits. [1215] atomic instruction — An embodiment word; software here speaks almost directly to silicon or wire. [1216] bandwidth {HW} — A near-metal word; it matters when abstraction is no longer cheap enough. [1217] barrier {HW} — A rendezvous word; no party crosses until all required parties arrive. [1218] bit width — An embodiment word; software here speaks almost directly to silicon or wire. [1219] boot ROM — A performance-and-physics word; it governs timing, placement, and finite material limits. [1220] branch predictor — A performance-and-physics word; it governs timing, placement, and finite material limits. [1221] bus {HW} — A performance-and-physics word; it governs timing, placement, and finite material limits. [1222] cache {HW} — A nearness word; it keeps likely things close to reduce future cost. [1223] cache coherence — A machine-word; it reaches into clocks, buses, registers, or heat. [1224] cache line {HW} — A machine-word; it reaches into clocks, buses, registers, or heat. [1225] clock — A machine-word; it reaches into clocks, buses, registers, or heat. [1226] clock cycle — A machine-word; it reaches into clocks, buses, registers, or heat. [1227] co-processor — An embodiment word; software here speaks almost directly to silicon or wire. [1228] core {HW} — A near-metal word; it matters when abstraction is no longer cheap enough. [1229] CPU — A machine-word; it reaches into clocks, buses, registers, or heat. [1230] cycle budget — An embodiment word; software here speaks almost directly to silicon or wire. [1231] DMA — A performance-and-physics word; it governs timing, placement, and finite material limits. [1232] DRAM — A machine-word; it reaches into clocks, buses, registers, or heat. [1233] driver interrupt — A near-metal word; it matters when abstraction is no longer cheap enough. [1234] EEPROM — A machine-word; it reaches into clocks, buses, registers, or heat. [1235] endianness — A machine-word; it reaches into clocks, buses, registers, or heat. [1236] fence — A near-metal word; it matters when abstraction is no longer cheap enough. [1237] firmware {HW} — A near-metal word; it matters when abstraction is no longer cheap enough. [1238] flash — A performance-and-physics word; it governs timing, placement, and finite material limits. [1239] FPGA — A performance-and-physics word; it governs timing, placement, and finite material limits. [1240] frame budget — A performance-and-physics word; it governs timing, placement, and finite material limits. [1241] frequency — A performance-and-physics word; it governs timing, placement, and finite material limits. [1242] GPIO — An embodiment word; software here speaks almost directly to silicon or wire. [1243] GPU — A machine-word; it reaches into clocks, buses, registers, or heat. [1244] heat budget — A near-metal word; it matters when abstraction is no longer cheap enough. [1245] I2C — A performance-and-physics word; it governs timing, placement, and finite material limits. [1246] instruction cache — A performance-and-physics word; it governs timing, placement, and finite material limits. [1247] instruction pointer — An embodiment word; software here speaks almost directly to silicon or wire. [1248] interrupt service routine — A machine-word; it reaches into clocks, buses, registers, or heat. [1249] ioctl boundary — An embodiment word; software here speaks almost directly to silicon or wire. [1250] IPC cost — A near-metal word; it matters when abstraction is no longer cheap enough. [1251] ISA — A near-metal word; it matters when abstraction is no longer cheap enough. [1252] jitter {HW} — A timing-noise word; repeated operations arrive with unstable spacing. [1253] JTAG — A performance-and-physics word; it governs timing, placement, and finite material limits. [1254] kernel bypass — An embodiment word; software here speaks almost directly to silicon or wire. [1255] latency budget — An embodiment word; software here speaks almost directly to silicon or wire. [1256] memory channel — A performance-and-physics word; it governs timing, placement, and finite material limits. [1257] memory-mapped I/O — A machine-word; it reaches into clocks, buses, registers, or heat. [1258] microcode — A near-metal word; it matters when abstraction is no longer cheap enough. [1259] MMIO — A performance-and-physics word; it governs timing, placement, and finite material limits. [1260] NUMA — A near-metal word; it matters when abstraction is no longer cheap enough. [1261] NVRAM — A machine-word; it reaches into clocks, buses, registers, or heat. [1262] opcode {HW} — A performance-and-physics word; it governs timing, placement, and finite material limits. [1263] out-of-order execution — An embodiment word; software here speaks almost directly to silicon or wire. [1264] PCIe — A near-metal word; it matters when abstraction is no longer cheap enough. [1265] pipeline {HW} — A procession word; work passes through ordered stages. [1266] power budget — A machine-word; it reaches into clocks, buses, registers, or heat. [1267] prefetcher — A machine-word; it reaches into clocks, buses, registers, or heat. [1268] real-time {HW} — A machine-word; it reaches into clocks, buses, registers, or heat. [1269] register — A near-metal word; a tiny, privileged vessel close to execution itself. [1270] register file — A near-metal word; it matters when abstraction is no longer cheap enough. [1271] reset vector — A performance-and-physics word; it governs timing, placement, and finite material limits. [1272] ROM — A performance-and-physics word; it governs timing, placement, and finite material limits. [1273] RTOS — A machine-word; it reaches into clocks, buses, registers, or heat. [1274] runtime budget — An embodiment word; software here speaks almost directly to silicon or wire. [1275] sensor loop — A machine-word; it reaches into clocks, buses, registers, or heat. [1276] SIMD — A near-metal word; it matters when abstraction is no longer cheap enough. [1277] SPI — A machine-word; it reaches into clocks, buses, registers, or heat. [1278] SRAM — An embodiment word; software here speaks almost directly to silicon or wire. [1279] superscalar — A near-metal word; it matters when abstraction is no longer cheap enough. [1280] thermal throttling — A machine-word; it reaches into clocks, buses, registers, or heat. [1281] throughput — How much useful work the system can push through a narrow world in bounded time. Shadow: chasing bulk capacity while tail latency burns the user. [1282] timing window — A machine-word; it reaches into clocks, buses, registers, or heat. [1283] TPU — A near-metal word; it matters when abstraction is no longer cheap enough. [1284] UART — A machine-word; it reaches into clocks, buses, registers, or heat. [1285] utilization — A machine-word; it reaches into clocks, buses, registers, or heat. [1286] vector unit — An embodiment word; software here speaks almost directly to silicon or wire. [1287] volatile — A machine-word; it reaches into clocks, buses, registers, or heat. [1288] watchdog timer — A performance-and-physics word; it governs timing, placement, and finite material limits. [1289] wire speed — A machine-word; it reaches into clocks, buses, registers, or heat. [1290] zero-copy {HW} — A nearness-and-efficiency word; data moves without redundant duplication. ________________

Interface, UX, and Human-Facing Words Not all magic is low-level. Some words shape how software appears to minds and hands. These are words of visibility, affordance, navigation, feedback, responsiveness, and care. They are magical because they change what a system feels like to inhabit. [1291] accessibility — A human-facing word; it governs appearance, action, or understanding. [1292] adaptive layout — A human-facing word; it governs appearance, action, or understanding. [1293] affordance — An experience word; it changes how the system feels to inhabit. [1294] animation — A human-facing word; it governs appearance, action, or understanding. [1295] app shell — An experience word; it changes how the system feels to inhabit. [1296] breadcrumb — An interface word; it binds software intent to human attention and action. [1297] call to action — An experience word; it changes how the system feels to inhabit. [1298] click target — An experience word; it changes how the system feels to inhabit. [1299] component {UX} — An interface word; it binds software intent to human attention and action. [1300] confirmation — An experience word; it changes how the system feels to inhabit. [1301] copy — An interface word; it binds software intent to human attention and action. [1302] dark mode — An interface word; it binds software intent to human attention and action. [1303] discoverability — An experience word; it changes how the system feels to inhabit. [1304] empty state — A human-facing word; it governs appearance, action, or understanding. [1305] error state — An interface word; it binds software intent to human attention and action. [1306] feedback — An experience word; it changes how the system feels to inhabit. [1307] focus state — An experience word; it changes how the system feels to inhabit. [1308] form validation — An interface word; it binds software intent to human attention and action. [1309] gesture — An interface word; it binds software intent to human attention and action. [1310] grid — A visibility word; it shapes what users can notice, predict, or recover from. [1311] hierarchy {UX} — An interface word; it binds software intent to human attention and action. [1312] hover state — An experience word; it changes how the system feels to inhabit. [1313] hydration — A visibility word; it shapes what users can notice, predict, or recover from. [1314] input field — A human-facing word; it governs appearance, action, or understanding. [1315] interaction — A human-facing word; it governs appearance, action, or understanding. [1316] internationalization — A visibility word; it shapes what users can notice, predict, or recover from. [1317] keyboard navigation — An experience word; it changes how the system feels to inhabit. [1318] label {UX} — A human-facing word; it governs appearance, action, or understanding. [1319] layout {UX} — A visibility word; it shapes what users can notice, predict, or recover from. [1320] localization — An experience word; it changes how the system feels to inhabit. [1321] menu — An experience word; it changes how the system feels to inhabit. [1322] microcopy — An experience word; it changes how the system feels to inhabit. [1323] modal — An experience word; it changes how the system feels to inhabit. [1324] navigation — A human-facing word; it governs appearance, action, or understanding. [1325] offline-first {UX} — A human-facing word; it governs appearance, action, or understanding. [1326] onboarding — An interface word; it binds software intent to human attention and action. [1327] output view — A human-facing word; it governs appearance, action, or understanding. [1328] pagination control — An interface word; it binds software intent to human attention and action. [1329] panel — A human-facing word; it governs appearance, action, or understanding. [1330] placeholder — An interface word; it binds software intent to human attention and action. [1331] progressive disclosure — A visibility word; it shapes what users can notice, predict, or recover from. [1332] prompt surface {UX} — An interface word; it binds software intent to human attention and action. [1333] responsive design — A human-facing word; it governs appearance, action, or understanding. [1334] screen — A human-facing word; it governs appearance, action, or understanding. [1335] scroll state — A human-facing word; it governs appearance, action, or understanding. [1336] search box — An interface word; it binds software intent to human attention and action. [1337] selection — A visibility word; it shapes what users can notice, predict, or recover from. [1338] skeleton state — A visibility word; it shapes what users can notice, predict, or recover from. [1339] state transition — A human-facing word; it governs appearance, action, or understanding. [1340] stepper — An interface word; it binds software intent to human attention and action. [1341] sync state — A visibility word; it shapes what users can notice, predict, or recover from. [1342] table view — An interface word; it binds software intent to human attention and action. [1343] theme — An interface word; it binds software intent to human attention and action. [1344] tooltip — An interface word; it binds software intent to human attention and action. [1345] typography — An interface word; it binds software intent to human attention and action. [1346] user flow — An interface word; it binds software intent to human attention and action. [1347] validation message — A human-facing word; it governs appearance, action, or understanding. [1348] view model — A human-facing word; it governs appearance, action, or understanding. [1349] viewport — A human-facing word; it governs appearance, action, or understanding. [1350] visual hierarchy — An interface word; it binds software intent to human attention and action. ________________

Promptcraft, AI-Oriented Engineering, and Spell Structure This house names the modern conjuration surface: prompts, tools, retrieval, evaluation, guardrails, and the clauses by which human intention is shaped into machine output. Because the user asked explicitly about spells, this house also contains meta-words that belong to spell construction itself: role, objective, context, constraint, procedure, output contract, verification, and fallback. [1351] agent {AI} — An acting word; a named locus of initiative that may observe, decide, and invoke tools. [1352] alignment {AI} — A prompting word; it belongs to the ritual surface between human specification and machine response. [1353] annotation set — A prompting word; it belongs to the ritual surface between human specification and machine response. [1354] benchmark prompt — A spellcraft word; it shapes how intent is framed before generation begins. [1355] canonical form {AI} — A normalization word; many possible surfaces are forced into one agreed shape. [1356] citation — A prompting word; it belongs to the ritual surface between human specification and machine response. [1357] clause marker — A prompting word; it belongs to the ritual surface between human specification and machine response. [1358] constraint {AI} — A bounding word; it removes degrees of freedom in order to improve correctness. [1359] context — A surrounding word; it supplies the conditions under which symbols acquire force. [1360] context window — A horizon word; it marks how much text the model can keep active at once. [1361] delegation — A conjuration word; it directs probabilistic software by language, retrieval, or evaluation. [1362] deterministic decoding — A spellcraft word; it shapes how intent is framed before generation begins. [1363] embedding {AI} — A closeness word; it places meaning into geometry. [1364] evaluation {AI} — A conjuration word; it directs probabilistic software by language, retrieval, or evaluation. [1365] evaluator — A prompting word; it belongs to the ritual surface between human specification and machine response. [1366] example — A conjuration word; it directs probabilistic software by language, retrieval, or evaluation. [1367] exemplar — A model-steering word; it affects what the system attends to, emits, or verifies. [1368] fallback {AI} — A conjuration word; it directs probabilistic software by language, retrieval, or evaluation. [1369] few-shot — A spellcraft word; it shapes how intent is framed before generation begins. [1370] fine-tuning — A conjuration word; it directs probabilistic software by language, retrieval, or evaluation. [1371] function call — A model-steering word; it affects what the system attends to, emits, or verifies. [1372] goal — An aim word; it tells the spell what outcome matters most. [1373] grounding — A spellcraft word; it shapes how intent is framed before generation begins. [1374] guardrail — A limiting word; it narrows the model’s allowed behavior without fully specifying the answer. [1375] hallucination check — A skepticism word; it forces the model to verify rather than merely continue. [1376] instruction {AI} — A model-steering word; it affects what the system attends to, emits, or verifies. [1377] latent space — A conjuration word; it directs probabilistic software by language, retrieval, or evaluation. [1378] memory {AI} — A spellcraft word; it shapes how intent is framed before generation begins. [1379] message role — A prompting word; it belongs to the ritual surface between human specification and machine response. [1380] multimodal — A conjuration word; it directs probabilistic software by language, retrieval, or evaluation. [1381] normal form — A spellcraft word; it shapes how intent is framed before generation begins. [1382] objective — A directing word; it states what the spell is trying to cause. [1383] output contract — A form-binding word; it specifies the shape the answer must take. [1384] parser prompt — A prompting word; it belongs to the ritual surface between human specification and machine response. [1385] plan — A prompting word; it belongs to the ritual surface between human specification and machine response. [1386] planner — A sequencing word; it arranges acts before they are executed. [1387] policy prompt — A model-steering word; it affects what the system attends to, emits, or verifies. [1388] procedure {AI} — A method word; not just what to do, but in what order to do it. [1389] prompt — A conjuration word; it biases a generative system toward a role, task, and style of action. [1390] prompt injection — A spellcraft word; it shapes how intent is framed before generation begins. [1391] prompt surface {AI} — A prompting word; it belongs to the ritual surface between human specification and machine response. [1392] ranking — A model-steering word; it affects what the system attends to, emits, or verifies. [1393] reasoning trace — A spellcraft word; it shapes how intent is framed before generation begins. [1394] reranker — A refinement word; candidates are reordered after an earlier retrieval pass. [1395] retrieval — A model-steering word; it affects what the system attends to, emits, or verifies. [1396] retrieval-augmented generation — A spellcraft word; it shapes how intent is framed before generation begins. [1397] role {AI} — An invocation word; it frames what kind of actor the model should pretend to be. [1398] rubric — A prompting word; it belongs to the ritual surface between human specification and machine response. [1399] safety rail — A conjuration word; it directs probabilistic software by language, retrieval, or evaluation. [1400] scaffold {AI} — A model-steering word; it affects what the system attends to, emits, or verifies. [1401] schema {AI} — A shape word for stored meaning. [1402] section marker — A prompting word; it belongs to the ritual surface between human specification and machine response. [1403] self-check — A spellcraft word; it shapes how intent is framed before generation begins. [1404] shot — A model-steering word; it affects what the system attends to, emits, or verifies. [1405] spell — A structured instruction artifact that binds role, goal, context, constraints, procedure, and verification into one operative text. [1406] spell number — A Gödel-style identifier for a canonicalized spell sequence. [1407] spell signature — A canonical token sequence or prime-exponent form standing in for an entire prompt. [1408] step list — A conjuration word; it directs probabilistic software by language, retrieval, or evaluation. [1409] system prompt — A throne word; it sits above later instructions and frames the entire interaction. [1410] task framing — A prompting word; it belongs to the ritual surface between human specification and machine response. [1411] temperature — A variance word in sampling; higher values loosen the model’s preference ordering. [1412] token {AI} — A countable unit of text or symbol used for parsing, modeling, or encoding. [1413] token stream — A spellcraft word; it shapes how intent is framed before generation begins. [1414] tool call — An extension word; the model reaches beyond text into an external operation. [1415] toolformer pattern — A prompting word; it belongs to the ritual surface between human specification and machine response. [1416] top-k — A prompting word; it belongs to the ritual surface between human specification and machine response. [1417] top-p — A conjuration word; it directs probabilistic software by language, retrieval, or evaluation. [1418] user prompt — A spellcraft word; it shapes how intent is framed before generation begins. [1419] verification {AI} — A truth-checking word that asks not merely for output, but for justified output. [1420] vocabulary id — A spellcraft word; it shapes how intent is framed before generation begins. ________________

Guarantee Words, Quality Attributes, and Behavioral Adjectives Some software words are adjectives, but they do more than decorate. They promise a behavioral law. To say a system is atomic, memory-safe, deterministic, portable, or observable is to place it under a strong claim. These are therefore guarantee words: adjectives with operational consequence. [1421] accessible — A property word; it says what kind of behavior should remain true under stress. [1422] adaptive — A property word; it says what kind of behavior should remain true under stress. [1423] amortized — A virtue word; it names an operational quality that can guide design and evaluation. [1424] approximate {Qual} — A property word; it says what kind of behavior should remain true under stress. [1425] atomic — No halfway state is allowed to leak across the line. Use it when partial success would be indistinguishable from corruption. [1426] auditable — A virtue word; it names an operational quality that can guide design and evaluation. [1427] authenticated — A virtue word; it names an operational quality that can guide design and evaluation. [1428] authoritative — A promise adjective; it binds the system to a stronger form of conduct. [1429] available — A promise adjective; it binds the system to a stronger form of conduct. [1430] backward-compatible — A guarantee word; it claims a behavioral law rather than a mere preference. [1431] balanced — A property word; it says what kind of behavior should remain true under stress. [1432] batched — A virtue word; it names an operational quality that can guide design and evaluation. [1433] bounded — A promise adjective; it binds the system to a stronger form of conduct. [1434] cache-friendly — A property word; it says what kind of behavior should remain true under stress. [1435] canonical — A guarantee word; it claims a behavioral law rather than a mere preference. [1436] causal — A promise adjective; it binds the system to a stronger form of conduct. [1437] composable — A promise adjective; it binds the system to a stronger form of conduct. [1438] concurrent — A virtue word; it names an operational quality that can guide design and evaluation. [1439] configurable — A promise adjective; it binds the system to a stronger form of conduct. [1440] consistent — A property word; it says what kind of behavior should remain true under stress. [1441] convergent — A virtue word; it names an operational quality that can guide design and evaluation. [1442] crash-safe — A promise adjective; it binds the system to a stronger form of conduct. [1443] declarative — A guarantee word; it claims a behavioral law rather than a mere preference. [1444] deduplicated — A guarantee word; it claims a behavioral law rather than a mere preference. [1445] deterministic — Given the same inputs, the same result should return. This is the antidote to drift, heisenbugs, and unreviewable behavior. [1446] durable — A virtue word; it names an operational quality that can guide design and evaluation. [1447] eager — A guarantee word; it claims a behavioral law rather than a mere preference. [1448] elastic — A promise adjective; it binds the system to a stronger form of conduct. [1449] encrypted — A property word; it says what kind of behavior should remain true under stress. [1450] eventual — A guarantee word; it claims a behavioral law rather than a mere preference. [1451] exact — A promise adjective; it binds the system to a stronger form of conduct. [1452] exhaustive — A property word; it says what kind of behavior should remain true under stress. [1453] extensible — A virtue word; it names an operational quality that can guide design and evaluation. [1454] fault-tolerant — A resilience word; some breakage is expected and survivable. [1455] federated — A guarantee word; it claims a behavioral law rather than a mere preference. [1456] formal — A promise adjective; it binds the system to a stronger form of conduct. [1457] generic {Qual} — A promise adjective; it binds the system to a stronger form of conduct. [1458] hardened — A virtue word; it names an operational quality that can guide design and evaluation. [1459] hermetic — A promise adjective; it binds the system to a stronger form of conduct. [1460] high-availability — A guarantee word; it claims a behavioral law rather than a mere preference. [1461] idempotent — The word that makes retries survivable: same request, same lasting effect. Shadow: duplicate charges, duplicate emails, and fear of recovery. [1462] immutable — Once written, this thing does not change in place. Immutability buys clarity, replayability, and safer sharing at the cost of update convenience. [1463] incremental — A property word; it says what kind of behavior should remain true under stress. [1464] indexed — A promise adjective; it binds the system to a stronger form of conduct. [1465] isolated — A promise adjective; it binds the system to a stronger form of conduct. [1466] lazy — A guarantee word; it claims a behavioral law rather than a mere preference. [1467] linearizable — Every operation behaves as though it took effect at one real instant visible to all observers. Use it rarely, but mean it fully. [1468] lock-free {Qual} — A progress word; some thread always moves forward without a lock. [1469] lossless — A guarantee word; it claims a behavioral law rather than a mere preference. [1470] lossy — A property word; it says what kind of behavior should remain true under stress. [1471] maintainable — A promise adjective; it binds the system to a stronger form of conduct. [1472] memory-safe {Qual} — A promise that the system will not casually trespass across allocation boundaries. Shadow: leaks, corruption, and security bugs born from illegal touch. [1473] modular — A guarantee word; it claims a behavioral law rather than a mere preference. [1474] observable — A promise adjective; it binds the system to a stronger form of conduct. [1475] opaque — A virtue word; it names an operational quality that can guide design and evaluation. [1476] orthogonal — A promise adjective; it binds the system to a stronger form of conduct. [1477] parallel {Qual} — A promise adjective; it binds the system to a stronger form of conduct. [1478] portable — A promise adjective; it binds the system to a stronger form of conduct. [1479] predictable — A virtue word; it names an operational quality that can guide design and evaluation. [1480] private — A virtue word; it names an operational quality that can guide design and evaluation. [1481] pure — Same inputs, same output, no hidden state smuggled in from the side. Use it to shrink reasoning scope. [1482] reactive — A virtue word; it names an operational quality that can guide design and evaluation. [1483] reentrant — A safe-return word; the same code may be entered again before the first invocation finishes. [1484] reliable — A guarantee word; it claims a behavioral law rather than a mere preference. [1485] reproducible — A guarantee word; it claims a behavioral law rather than a mere preference. [1486] resilient — A virtue word; it names an operational quality that can guide design and evaluation. [1487] responsive — A property word; it says what kind of behavior should remain true under stress. [1488] safe — A guarded word; some class of failure is explicitly ruled out. [1489] sandboxed — A guarantee word; it claims a behavioral law rather than a mere preference. [1490] scalable — A virtue word; it names an operational quality that can guide design and evaluation. [1491] secure — A virtue word; it names an operational quality that can guide design and evaluation. [1492] serializable {Qual} — Concurrency forced to behave as though transactions happened in one clean order. Expensive when overused, indispensable when history must remain sane. [1493] sharded — A virtue word; it names an operational quality that can guide design and evaluation. [1494] side-effect-free {Qual} — A property word; it says what kind of behavior should remain true under stress. [1495] signed — A property word; it says what kind of behavior should remain true under stress. [1496] stable — A virtue word; it names an operational quality that can guide design and evaluation. [1497] stateful — A guarantee word; it claims a behavioral law rather than a mere preference. [1498] stateless — A guarantee word; it claims a behavioral law rather than a mere preference. [1499] streaming — A property word; it says what kind of behavior should remain true under stress. [1500] strict — A promise adjective; it binds the system to a stronger form of conduct. [1501] synchronized — A guarantee word; it claims a behavioral law rather than a mere preference. [1502] testable — A guarantee word; it claims a behavioral law rather than a mere preference. [1503] thread-safe — A guarantee word; it claims a behavioral law rather than a mere preference. [1504] traceable — A virtue word; it names an operational quality that can guide design and evaluation. [1505] transactional — A virtue word; it names an operational quality that can guide design and evaluation. [1506] typed — A property word; it says what kind of behavior should remain true under stress. [1507] validated — A property word; it says what kind of behavior should remain true under stress. [1508] vectorized — A virtue word; it names an operational quality that can guide design and evaluation. [1509] verified — A property word; it says what kind of behavior should remain true under stress. [1510] versioned — A virtue word; it names an operational quality that can guide design and evaluation. [1511] wait-free {Qual} — A guarantee word; it claims a behavioral law rather than a mere preference. [1512] zero-copy {Qual} — A nearness-and-efficiency word; data moves without redundant duplication. ________________

Failure Words, Pathologies, and Counter-Spells Every magical vocabulary has curse words. In software these are the names of bad states, pathological timing, corrupted boundaries, and violated assumptions. Knowing the names matters because unnamed failures tend to masquerade as mystery. [1513] anomaly — A pathology word; it describes how systems break, stall, or lie. [1514] backlog collapse — A counter-spell word; it marks the shadow that disciplined engineering tries to prevent. [1515] broken pipe — A failure-name; it gives shape to an otherwise vague loss of correctness or service. [1516] bug — A counter-spell word; it marks the shadow that disciplined engineering tries to prevent. [1517] cascading failure — A pathology word; it describes how systems break, stall, or lie. [1518] checksum mismatch — A pathology word; it describes how systems break, stall, or lie. [1519] collision — A curse-word; it names a bad state so it can stop masquerading as mystery. [1520] contention — A pathology word; it describes how systems break, stall, or lie. [1521] corruption — A pathology word; it describes how systems break, stall, or lie. [1522] crash — A pathology word; it describes how systems break, stall, or lie. [1523] curse of shared state — A failure-name; it gives shape to an otherwise vague loss of correctness or service. [1524] data drift — A failure-name; it gives shape to an otherwise vague loss of correctness or service. [1525] deadlock {Curse} — A binding curse; multiple actors wait on one another forever. [1526] defect — A failure-name; it gives shape to an otherwise vague loss of correctness or service. [1527] degraded mode — A pathology word; it describes how systems break, stall, or lie. [1528] denial of service — A failure-name; it gives shape to an otherwise vague loss of correctness or service. [1529] dependency hell — A curse-word; it names a bad state so it can stop masquerading as mystery. [1530] divergence — A curse-word; it names a bad state so it can stop masquerading as mystery. [1531] drift — A pathology word; it describes how systems break, stall, or lie. [1532] error — A counter-spell word; it marks the shadow that disciplined engineering tries to prevent. [1533] exception — A failure-name; it gives shape to an otherwise vague loss of correctness or service. [1534] exhaustion — A curse-word; it names a bad state so it can stop masquerading as mystery. [1535] failure domain — A curse-word; it names a bad state so it can stop masquerading as mystery. [1536] fault — A curse-word; it names a bad state so it can stop masquerading as mystery. [1537] flapping — A pathology word; it describes how systems break, stall, or lie. [1538] fragmentation — A failure-name; it gives shape to an otherwise vague loss of correctness or service. [1539] freeze — A pathology word; it describes how systems break, stall, or lie. [1540] hang — A counter-spell word; it marks the shadow that disciplined engineering tries to prevent. [1541] hotspot — A pathology word; it describes how systems break, stall, or lie. [1542] inconsistent read — A pathology word; it describes how systems break, stall, or lie. [1543] infinite loop — A curse-word; it names a bad state so it can stop masquerading as mystery. [1544] invalid state — A curse-word; it names a bad state so it can stop masquerading as mystery. [1545] jitter spike — A counter-spell word; it marks the shadow that disciplined engineering tries to prevent. [1546] leak {Curse} — Something escapes the boundary that should have held it: memory, secrets, file descriptors, authority, abstraction, or time. [1547] livelock — A pathology word; it describes how systems break, stall, or lie. [1548] lost update — A pathology word; it describes how systems break, stall, or lie. [1549] memory corruption — A counter-spell word; it marks the shadow that disciplined engineering tries to prevent. [1550] mismatch — A counter-spell word; it marks the shadow that disciplined engineering tries to prevent. [1551] misroute — A curse-word; it names a bad state so it can stop masquerading as mystery. [1552] missed heartbeat — A pathology word; it describes how systems break, stall, or lie. [1553] null dereference — A failure-name; it gives shape to an otherwise vague loss of correctness or service. [1554] outage — A pathology word; it describes how systems break, stall, or lie. [1555] overflow — A curse-word; it names a bad state so it can stop masquerading as mystery. [1556] packet loss {Curse} — A pathology word; it describes how systems break, stall, or lie. [1557] panic — A failure-name; it gives shape to an otherwise vague loss of correctness or service. [1558] partial failure — A pathology word; it describes how systems break, stall, or lie. [1559] partition storm — A failure-name; it gives shape to an otherwise vague loss of correctness or service. [1560] poison pill — A pathology word; it describes how systems break, stall, or lie. [1561] race — An ordering curse: outcomes depend on timing you do not actually control. Name the race and the system becomes debuggable again. [1562] regression — A pathology word; it describes how systems break, stall, or lie. [1563] resource starvation — A failure-name; it gives shape to an otherwise vague loss of correctness or service. [1564] retry storm — Recovery logic amplifying failure instead of containing it. Unguided retries can turn a partial outage into a self-made siege. [1565] rollback failure — A counter-spell word; it marks the shadow that disciplined engineering tries to prevent. [1566] saturation — A counter-spell word; it marks the shadow that disciplined engineering tries to prevent. [1567] schema drift — The stored world and the assumed world have silently stopped matching. This is how migrations keep hurting after everyone thinks they are done. [1568] split-brain {Curse} — A pathology word; it describes how systems break, stall, or lie. [1569] stack overflow — A counter-spell word; it marks the shadow that disciplined engineering tries to prevent. [1570] stale read — A pathology word; it describes how systems break, stall, or lie. [1571] stall — A curse-word; it names a bad state so it can stop masquerading as mystery. [1572] starvation — A failure-name; it gives shape to an otherwise vague loss of correctness or service. [1573] state explosion — A counter-spell word; it marks the shadow that disciplined engineering tries to prevent. [1574] storm — A pathology word; it describes how systems break, stall, or lie. [1575] thrash — A counter-spell word; it marks the shadow that disciplined engineering tries to prevent. [1576] timeout {Curse} — A patience-bound word; after a duration, waiting is no longer allowed. [1577] torn write — A counter-spell word; it marks the shadow that disciplined engineering tries to prevent. [1578] underflow — A counter-spell word; it marks the shadow that disciplined engineering tries to prevent. [1579] unhandled exception — A counter-spell word; it marks the shadow that disciplined engineering tries to prevent. [1580] unstable equilibrium — A counter-spell word; it marks the shadow that disciplined engineering tries to prevent. [1581] write amplification — A failure-name; it gives shape to an otherwise vague loss of correctness or service. [1582] write skew {Curse} — A pathology word; it describes how systems break, stall, or lie. ________________

Compound Forms, Prefixes, Suffixes, and Naming Runes Software magic is not made only of standalone words. It is also made of reusable affixes, compounds, and naming patterns. These runes change meaning by attachment: a suffix like -safe or -aware, a prefix like re- or de-, or a compound like control plane or single source of truth. [1583] -able — A compositional word-form; it carries repeated design intent across many contexts. [1584] -aware — A compositional word-form; it carries repeated design intent across many contexts. [1585] -by-design — A semantic affix or compound; it compresses a recurring engineering pattern into a compact mark. [1586] -centric — A compositional word-form; it carries repeated design intent across many contexts. [1587] -complete — A pattern rune; its power comes from how it modifies neighboring terms. [1588] -driven — A compositional word-form; it carries repeated design intent across many contexts. [1589] -first — A compositional word-form; it carries repeated design intent across many contexts. [1590] -free — A semantic affix or compound; it compresses a recurring engineering pattern into a compact mark. [1591] -friendly — A pattern rune; its power comes from how it modifies neighboring terms. [1592] -hard — A naming rune; it changes meaning by attachment or compound form. [1593] -less — A naming rune; it changes meaning by attachment or compound form. [1594] -local — A naming rune; it changes meaning by attachment or compound form. [1595] -native — A naming rune; it changes meaning by attachment or compound form. [1596] -of-record — A pattern rune; its power comes from how it modifies neighboring terms. [1597] -oriented — A semantic affix or compound; it compresses a recurring engineering pattern into a compact mark. [1598] -safe — A naming rune; it changes meaning by attachment or compound form. [1599] -sensitive — A semantic affix or compound; it compresses a recurring engineering pattern into a compact mark. [1600] -shaped — A pattern rune; its power comes from how it modifies neighboring terms. [1601] -soft — A compositional word-form; it carries repeated design intent across many contexts. [1602] -tolerant — A pattern rune; its power comes from how it modifies neighboring terms. [1603] -wide — A pattern rune; its power comes from how it modifies neighboring terms. [1604] actor model — A pattern rune; its power comes from how it modifies neighboring terms. [1605] API-first — A semantic affix or compound; it compresses a recurring engineering pattern into a compact mark. [1606] append-only — A semantic affix or compound; it compresses a recurring engineering pattern into a compact mark. [1607] best-effort — A compositional word-form; it carries repeated design intent across many contexts. [1608] branch-free — A compositional word-form; it carries repeated design intent across many contexts. [1609] cloud-native — A semantic affix or compound; it compresses a recurring engineering pattern into a compact mark. [1610] command-query — A pattern rune; its power comes from how it modifies neighboring terms. [1611] control plane {Rune} — A compositional word-form; it carries repeated design intent across many contexts. [1612] copy-on-write {Rune} — A compositional word-form; it carries repeated design intent across many contexts. [1613] crash-only — A naming rune; it changes meaning by attachment or compound form. [1614] data plane {Rune} — A pattern rune; its power comes from how it modifies neighboring terms. [1615] data-driven — A semantic affix or compound; it compresses a recurring engineering pattern into a compact mark. [1616] default-deny — A pattern rune; its power comes from how it modifies neighboring terms. [1617] edge-native — A compositional word-form; it carries repeated design intent across many contexts. [1618] event-driven — A semantic affix or compound; it compresses a recurring engineering pattern into a compact mark. [1619] eventually consistent — A semantic affix or compound; it compresses a recurring engineering pattern into a compact mark. [1620] fail-fast — A semantic affix or compound; it compresses a recurring engineering pattern into a compact mark. [1621] first-class — A semantic affix or compound; it compresses a recurring engineering pattern into a compact mark. [1622] hot path {Rune} — A naming rune; it changes meaning by attachment or compound form. [1623] infrastructure-as-code — A pattern rune; its power comes from how it modifies neighboring terms. [1624] least-authority — A semantic affix or compound; it compresses a recurring engineering pattern into a compact mark. [1625] lock-free {Rune} — A progress word; some thread always moves forward without a lock. [1626] machine-readable — A pattern rune; its power comes from how it modifies neighboring terms. [1627] memory-safe {Rune} — A compositional word-form; it carries repeated design intent across many contexts. [1628] multi-tenant — A pattern rune; its power comes from how it modifies neighboring terms. [1629] negative cache — A semantic affix or compound; it compresses a recurring engineering pattern into a compact mark. [1630] object-capability — A pattern rune; its power comes from how it modifies neighboring terms. [1631] offline-first {Rune} — A naming rune; it changes meaning by attachment or compound form. [1632] policy-as-code — A compositional word-form; it carries repeated design intent across many contexts. [1633] queue-backed — A naming rune; it changes meaning by attachment or compound form. [1634] read path — A compositional word-form; it carries repeated design intent across many contexts. [1635] read-through cache — A pattern rune; its power comes from how it modifies neighboring terms. [1636] real-time {Rune} — A naming rune; it changes meaning by attachment or compound form. [1637] rule-based — A naming rune; it changes meaning by attachment or compound form. [1638] side-effect-free {Rune} — A pattern rune; its power comes from how it modifies neighboring terms. [1639] single source of truth — A semantic affix or compound; it compresses a recurring engineering pattern into a compact mark. [1640] soft delete — A semantic affix or compound; it compresses a recurring engineering pattern into a compact mark. [1641] statefulset — A naming rune; it changes meaning by attachment or compound form. [1642] write path — A naming rune; it changes meaning by attachment or compound form. [1643] write-through cache — A compositional word-form; it carries repeated design intent across many contexts. [1644] zero-downtime — A naming rune; it changes meaning by attachment or compound form. [1645] zero-knowledge — A compositional word-form; it carries repeated design intent across many contexts. ________________

9. Closing Note A software grimoire can never be final, because new runtimes, architectures, languages, threats, and prompting surfaces continuously generate new words of force. But even an unfinished grimoire is useful if it helps the reader notice which words are merely descriptive and which words are operative. The practical lesson is simple: when you want reliable software outcomes—whether from a human team, a compiler, or an AI system—name the world carefully, bound the task, state the constraints, require a shape of answer, and ask for verification. That is promptcraft. That is software spellcraft. The rest is arrangement. pocket

Pocket Grimoire of Software Spellcraft Field Edition: 300 high-force runes, six software spells, one working theory of promptcraft. Distilled from The Grimoire of Software Magic Words · Public Release v1

For engineers who want prompts that behave more like disciplined instruments and less like wishes.

March 2026 · Pocket Edition v1.0 ________________

How to Use This Book The master grimoire is for depth. This pocket edition is for the desk, the backpack, the second monitor, and the incident room. It keeps only what repeatedly earns its keep in real software work: the operative laws, the spell skeleton, six reusable engineering spells, the fifty world-running words, and a field canon of three hundred high-force runes. Use it in three passes: first learn the cast levels, then steal the example spells, then browse the lexicon until the words begin to arrange themselves more deliberately in your prompts, reviews, and designs. Inside • Field doctrine — what makes a software word operative. • Cast levels and the canonical spell skeleton. • Workflow and pathologies for real AI-assisted engineering. • A short note on sigils, seals, and coil inspection. • Six ready-made software spells. • The Fifty World-Running Words. • A pocket lexicon of 300 high-force runes arranged by house and sigil range. Master sigil map [0001] Architecture, Abstraction, and Design [0001-0112] — Seams, layers, interfaces, models, and the shape of responsibility. [0113] Language, Semantics, and Formal Shape [0113-0249] — How software means before it runs: syntax, type, parsing, compilation. [0250] Data, State, and Representation [0250-0371] — The shapes in which meaning is stored, moved, and compared. [0372] Transformation, Algorithms, and Working Verbs [0372-0511] — The actions that turn one shape into another. [0512] Control Flow, Coordination, and Temporal Logic [0512-0608] — Time, waiting, ordering, retries, and concurrency. [0609] Runtime, Memory, and Execution [0609-0684] — Where code lives while running and what it costs to keep it alive. [0685] Systems Programming and Operating-System Words [0685-0770] — Kernel surfaces, files, processes, descriptors, and host bargains. [0771] Networking and Distributed Systems [0771-0886] — Distance, coordination, consensus, routing, and failure across nodes. [0887] Databases, Persistence, and Time-Binding Words [0887-0968] — Stored truth, transactional law, indexes, migration, and rollback. [0969] Security, Trust, and Warding Words [0969-1063] — Identity, permission, secrecy, integrity, and defensive boundaries. [1064] Build, Tooling, Versioning, and Release [1064-1139] — How software is assembled, tracked, tested, and shipped. [1140] Testing, Verification, and Observability [1140-1210] — Evidence surfaces: tests, metrics, traces, profilers, and invariants. [1211] Hardware, Embedded, and Performance-Near Words [1211-1290] — When software starts bargaining with silicon, buses, timing, and heat. [1291] Interface, UX, and Human-Facing Words [1291-1350] — The names that shape attention, action, feedback, and usability. [1351] Promptcraft, AI-Oriented Engineering, and Spell Structure [1351-1420] — Role, context, retrieval, verification, tools, and prompt form. [1421] Guarantee Words and Quality Attributes [1421-1512] — The adjectives that claim durable behavioral law. [1513] Failure Words, Pathologies, and Counter-Spells [1513-1582] — The names engineers use when systems lie, stall, diverge, or collapse. [1583] Naming Runes, Affixes, and Compound Forms [1583-1645] — The modifiers that quietly shift design intent when attached to other words. I. Field Doctrine This pocket edition begins from a practical claim: some software words do more work than others. A normal word describes. A magic word compresses, constrains, invokes, protects, or exposes. It tells a compiler what law must hold, a reviewer what risk matters, a runtime what surface may be touched, or a model what shape an answer must take. Software is unusually fertile ground for this because computing is built from named abstractions that must cooperate under strict conditions. A change to the word idempotent, linearizable, rollback, schema, policy, or timeout is not ornament. It is often a change to the system’s actual future. Three sources of force • Semantic density — A magic word compresses a large conceptual bundle into a small token. • Invocation surface — The word matters because some person, compiler, runtime, database, reviewer, or model can respond to it. • Positional force — The same word does different work in a prompt, a type signature, an API contract, a migration plan, or an incident report. Five laws of the software magic word • Compression — High-force words carry more concept than their length suggests. • Placement — A word gains or loses force depending on where it is uttered. • Adjacency — Good runes amplify or constrain one another; bad neighboring words create ambiguity. • Verification — A spell is stronger when it binds itself to evidence and a checkable output shape. • Shadow — Every powerful word casts a failure shadow: race shadows concurrency, drift shadows schema, leak shadows allocation. The small practical definition A software spell is a deliberately shaped instruction artifact that binds role, objective, context, constraints, procedure, output shape, verification, and failure behavior tightly enough that a human or machine can act with less ambiguity and less waste. ________________

2. Casting Spells The full anatomy of a spell has eight limbs, but not every task needs full ritual weight. The goal is not ceremonial verbosity. The goal is minimum adequate structure. Cast levels Quick cast — ROLE | OBJECTIVE | CONTEXT | VERIFY. Use for bounded explanation, review, drafting, and low-risk edits. Working cast — ROLE | OBJECTIVE | CONTEXT | CONSTRAINTS | OUTPUT | VERIFY. Daily engineering form. Rich enough for real work without ceremonial overhead. Full ritual — ROLE | OBJECTIVE | CONTEXT | CONSTRAINTS | PROCEDURE | OUTPUT | VERIFY | FAILURE. Use for migrations, refactors, releases, agentic workflows, and anything that can damage durable state. Canonical spell skeleton ROLE: [what expertise is being invoked] OBJECTIVE: [what outcome matters most] CONTEXT: [local facts already true] CONSTRAINTS: [what must not break] PROCEDURE: [how the work should proceed] OUTPUT: [required answer shape] VERIFY: [how truth will be checked] FAILURE: [what to do if evidence is missing or unsafe] From wish to spell Weak — Design an API for billing. ROLE: act as a backend architect designing a public billing API. OBJECTIVE: produce a boring, versionable JSON API that supports invoices, payment attempts, refunds, and idempotent retries. CONTEXT: mobile and web clients; PostgreSQL storage; slow client upgrade cadence; OAuth-based auth. CONSTRAINTS: preserve backward compatibility, include pagination and error schema, prefer boring patterns over novelty. OUTPUT: endpoint table, request/response examples, auth notes, idempotency notes, migration/versioning notes. VERIFY: call out race conditions, retry hazards, and compatibility risks. ________________

Workflow and common prompt pathologies A useful spell can usually be repaired by walking the same sequence every time. Most prompt failure is not model mystery. It is missing structure. Practical workflow • Name the actor — Decide what expertise is being invoked. • Bind the outcome — Say what success means in operational terms, not wishes. • Load the local world — Versions, architecture, symptoms, traffic, dependencies, and facts already true. • Constrain the motion — State what must not break, what is banned, and where the blast radius must stop. • Choose the output shape — Diff, plan, checklist, test file, RFC, SQL, diagnosis table, benchmark plan. • Demand verification — Require checks, edge cases, invariants, or measurements. • Add failure behavior when risk rises — Tell the spell what to do if context is missing, contradictory, or unsafe. Common pathologies and the repair that usually fixes them Wish instead of objective — Replace ‘make this better’ with a measurable primary outcome. Context starvation — Load the local world: versions, constraints, symptoms, runtime, and adjacent systems. No constraint surface — Say what must not break, what may not be changed, and what dependencies are off-limits. No output contract — Choose the answer shape so the model does not sprawl. No verification — Require invariants, tests, traces, benchmarks, or validation queries. No failure behavior — For risky work, specify what the model should do when evidence is insufficient. False certainty — Separate observations from hypotheses and make assumptions explicit. Overbroad autonomy — Bound the patch, the system surface, and the class of allowed actions. ________________

3. Sigils, Seals, and Coil Inspection The public field version keeps numeric spellcraft practical. You do not need to hand-compute prime exponents in order to benefit from canonicalization. What matters is that spells can be normalized, named, compared, versioned, and eventually tooled. Three identifiers • Human title — the readable name used in docs and conversation. • Working seal — a short practical digest or stable token stream used in tools, repos, and prompt registries. • Formal sigil — the canonical spell identity after normalization; useful for archives, diffs, and exact reproduction. Use the human title in docs, the working seal in tools, and the formal sigil only when exact archival identity matters. The clause circle Field use does not require you to compute a Gödel product by hand. The point of numeric spellcraft is stable identity, not ritual arithmetic. Think of the seven active clauses on a prime circle — role, objective, context, constraints, procedure, output, verify — while failure behavior acts as a ward around the ring. Strong spells create useful antinodes: objective × verification and context × constraints. If the coil looks broken, the prompt probably is. Empty objective? Hollow antinode. No verification? Wishful magic. No constraints? The spell leaks into side effects it never meant to summon.

Clause circle (p = 7). Inspection, not ceremony. ________________

4. Six Field Spells These are ready-made working forms. Adapt the nouns, keep the structure, and insist on verification. Spell of Safe Refactoring Full ritual · Use when code quality must improve but public behavior must not move. ROLE: Act as a senior Python engineer performing behavior-preserving refactoring.

OBJECTIVE: Refactor the supplied module to reduce duplication and improve readability without changing public behavior.

CONTEXT: Python 3.12. The module runs inside a web API process and is called on every request. Existing tests are incomplete. Function signatures are part of a stable public API.

CONSTRAINTS: Do not add third-party dependencies. Do not change public names, parameter order, or return schema. Preserve current logging side effects unless they are obviously duplicated.

PROCEDURE: List invariants first. Identify duplication. Propose the minimal refactor and explain tradeoffs briefly.

OUTPUT CONTRACT: Return: (1) short summary, (2) invariants, (3) unified diff, (4) revised code, (5) targeted test plan.

VERIFICATION: Include empty-input, malformed-input, Unicode, and large-input cases. State why behavior is preserved.

FAILURE BEHAVIOR: If behavior cannot be inferred from the code, say what is ambiguous and proceed with the safest minimal change. ________________

Spell of Bug Diagnosis from Logs Full ritual · Use when logs are real but certainty is not, and you need ranked hypotheses instead of performance theater. ROLE: Act as a production incident engineer diagnosing a backend failure.

OBJECTIVE: Determine the most likely root causes of the supplied logs and propose the shortest safe path to confirmation and mitigation.

CONTEXT: Stateless containerized API backed by PostgreSQL and Redis. Latency SLO is 250 ms p95. A recent deploy occurred within the last hour.

CONSTRAINTS: Do not assume facts not present in the logs. Separate observations from hypotheses. Prefer reversible, low-risk mitigations and mention what to watch during mitigation.

PROCEDURE: Extract timeline, cluster repeated errors, identify likely failure domain, and rank hypotheses. For each hypothesis, give one confirming check and one mitigating action.

OUTPUT CONTRACT: Return: (1) confirmed observations, (2) ranked hypotheses, (3) immediate mitigation options, (4) confirmation steps, (5) rollback criteria.

VERIFICATION: Tie every claim to a concrete log line or to the absence of an expected line.

FAILURE BEHAVIOR: If the logs are insufficient, say what additional evidence would most reduce uncertainty. ________________

Spell of API Design Working cast · Use when the interface will outlive the first implementation and backward compatibility matters. ROLE: Act as a backend architect designing a public JSON API.

OBJECTIVE: Design an API for the described resource model that is clean, versionable, secure, and observable.

CONTEXT: Clients include web, mobile, and internal automation. OAuth-based authorization. PostgreSQL storage. Backward compatibility matters because mobile clients update slowly.

CONSTRAINTS: Prefer boring, maintainable patterns over novelty. Include pagination, error schema, idempotency where appropriate, authorization notes, and migration considerations. Do not hand-wave failure modes.

OUTPUT CONTRACT: Return: (1) resource model, (2) endpoint table, (3) example requests and responses, (4) error format, (5) auth model, (6) migration and versioning notes.

VERIFICATION: Call out edge cases, race conditions, and compatibility risks. ________________

Spell of Migration Without Data Loss Full ritual · Use when stored reality must change shape under live traffic and rollback still matters. ROLE: Act as a database migration engineer.

OBJECTIVE: Plan a schema and data migration that preserves correctness, minimizes downtime, and has a clear rollback strategy.

CONTEXT: PostgreSQL production database, high write volume, zero-downtime preference, mixed old and new application versions during rollout.

CONSTRAINTS: Assume the table is large. Avoid long exclusive locks where possible. Preserve existing reads during rollout. Include backfill strategy, validation queries, and rollback conditions.

PROCEDURE: Describe the expand-and-contract sequence: schema changes, compatibility window, backfill, validation, cutover, cleanup.

OUTPUT CONTRACT: Return: (1) migration phases, (2) SQL or pseudo-SQL snippets, (3) application changes required, (4) validation checklist, (5) rollback plan.

VERIFICATION: State how to verify row counts, nullability, foreign-key integrity, and read/write correctness at each phase.

FAILURE BEHAVIOR: If downtime or lock risk cannot be avoided, say so explicitly and estimate where the risk concentrates. ________________

Spell of Test Generation Working cast · Use when behavior is partly implicit and you need tests that reveal assumptions instead of flattering guesses. ROLE: Act as a meticulous test engineer.

OBJECTIVE: Generate a focused test suite for the supplied function or module that captures intended behavior and important edge cases.

CONTEXT: The code may be partially undocumented. Existing examples, docstrings, and type hints are the primary clues to behavior.

CONSTRAINTS: Prefer high-signal tests over high-count tests. Group tests by behavior. Avoid mocking unless boundaries require it. Call out assumptions whenever behavior is not explicit.

OUTPUT CONTRACT: Return: (1) inferred behaviors, (2) missing-behavior ambiguities, (3) the test file, (4) a short rationale for each test group.

VERIFICATION: Include nominal, boundary, error, and one regression-style case if appropriate.

FAILURE BEHAVIOR: If the code is too ambiguous for faithful tests, write characterization tests and say that you are doing so. ________________

Spell of Performance Tuning Working cast · Use when you need ranked bets, measurement discipline, and permission to say ‘profile first.’ ROLE: Act as a performance engineer.

OBJECTIVE: Identify likely causes of latency or throughput loss and propose optimizations ranked by expected benefit versus risk.

CONTEXT: The service has a strict latency budget and runs on commodity cloud hardware. A profiler or benchmark may or may not be available.

CONSTRAINTS: Do not recommend micro-optimizations before addressing algorithmic or I/O-bound issues. Separate CPU, memory, allocation, database, and network effects. Mention measurement strategy.

OUTPUT CONTRACT: Return: (1) bottleneck hypotheses, (2) what to measure, (3) optimization options ranked by expected payoff, (4) benchmark plan, (5) rollback criteria.

VERIFICATION: State how success will be measured and what regression risks need to be watched.

FAILURE BEHAVIOR: If evidence is insufficient, say what profile, trace, or benchmark data would most improve the recommendation. ________________

V. The Fifty World-Running Words Read these until they start appearing by reflex in your prompts, reviews, designs, migrations, and incident reports. They are not the only runes that matter. They are the ones that keep real systems from becoming fog. Boundaries, seams, and collaboration [0001] abstraction — A deliberate forgetting of detail so larger structure can be reasoned about without drowning in mechanism. Shadow: hiding the only failure that matters. [0002] adapter — A negotiated translator between unlike shapes. Use it when two systems must meet without infecting one another. Shadow: adapter jungles that preserve confusion rather than resolve it. [0006] API gateway — A threshold that centralizes entry, policy, and routing at the edge of a service world. Shadow: a convenience chokepoint that quietly becomes a monolith. [0012] boundary — The line that says where one responsibility ends and another begins. Shadow: porous edges that smear blame, ownership, and test scope. [0013] bounded context — A protection against semantic bleed: the same word may not mean the same thing in every subsystem. Shadow: false unification through shared names. [0030] coupling — The hidden tax paid when change in one place forces change elsewhere. Name it early if you want modularity to survive contact with reality. [0034] dependency inversion — Stable policy should not kneel before unstable detail. Shadow: concrete dependencies hard-wired into places that should remain portable. [0055] interface — A disciplined seam that lets unlike bodies cooperate without swapping internal organs. Shadow: tight coupling and type bleed. [0347] schema — The declared shape of stored meaning. Shadow: drift, silent coercion, and backward-incompatible surprise. [1152] contract test — A promise checked at the seam between systems. Use it when mocks are too flattering and end-to-end tests are too blunt. State, durable truth, and reversibility [1172] invariant — A law that must remain true while the rest of the system is allowed to move. If you cannot say the invariant, you probably do not yet understand the change. [0926] migration — Stored reality changing shape without being lost. Good migrations are staged, inspectable, and reversible long enough to discover what the data actually contains. [0898] commit — The moment a proposed change becomes durable history. Shadow: writing too early, before the world is actually ready to carry the new truth. [0943] rollback — Permission to retreat toward a previously trusted state. A system without rollback mistakes hope for safety. [0805] eventual consistency — Agreement postponed rather than denied. Shadow: stale reads treated as if they were fresh truth. [0848] quorum — Not everyone must agree, but enough must. This word turns distributed action into a threshold question instead of a unanimous fantasy. [1461] idempotent — The word that makes retries survivable: same request, same lasting effect. Shadow: duplicate charges, duplicate emails, and fear of recovery. [1425] atomic — No halfway state is allowed to leak across the line. Use it when partial success would be indistinguishable from corruption. [1445] deterministic — Given the same inputs, the same result should return. This is the antidote to drift, heisenbugs, and unreviewable behavior. [1492] serializable — Concurrency forced to behave as though transactions happened in one clean order. Expensive when overused, indispensable when history must remain sane. Runtime pressure, behavior, and operational physics [1481] pure — Same inputs, same output, no hidden state smuggled in from the side. Use it to shrink reasoning scope. [1462] immutable — Once written, this thing does not change in place. Immutability buys clarity, replayability, and safer sharing at the cost of update convenience. [0576] retry — Failure does not necessarily end the ritual; policy may permit another attempt. Shadow: blind repetition against a broken precondition. [0598] timeout — Waiting is not free and patience must have a boundary. A timeout is a contract with reality about how long uncertainty is allowed to persist. [0825] latency — The delay before useful work reaches the caller. Latency is what users feel even when throughput graphs look flattering. [1281] throughput — How much useful work the system can push through a narrow world in bounded time. Shadow: chasing bulk capacity while tail latency burns the user. [0778] backpressure — Resistance pushed upstream when demand outruns capacity. Without it, overload spreads faster than truth. [0615] cache — Keep likely things close so future cost falls. Shadow: stale truth delivered at machine speed. [0684] zero-copy — Data movement stripped down to the minimum number of duplications. Use it when the bottleneck is physical movement rather than arithmetic. [1472] memory-safe — A promise that the system will not casually trespass across allocation boundaries. Shadow: leaks, corruption, and security bugs born from illegal touch. Observation, release, and proof surfaces [1180] observability — Enough internal evidence exists that you can infer what the system is doing from the outside. Not logs alone: legible state under pressure. [1202] telemetry — Measurements leaving the system in a form other systems can compare, store, and alert on. Shadow: metric exhaust without explanatory power. [1204] trace — A preserved path through execution. Use it when the question is not only what failed, but where the causal thread first bent. [1146] benchmark — A performance claim forced to meet measurement. Benchmarks are where speed rhetoric either cashes out or dies. [1073] canary — A deliberately limited release whose job is to discover whether production reality agrees with the story told in staging. [1086] deploy — The crossing from forge to world. Many good ideas become bad facts only after they are actually shipped. [1088] diff — A visible account of what changed between one state and another. Good diffs make review local; bad diffs turn truth into fog. [1186] property-based test — Instead of checking one remembered example, ask whether a law survives many generated cases. Use it when you care more about the invariant than the anecdote. [0974] attestation — A proof that a thing is what it claims to be or was produced the way it claims. It matters most when trust cannot be assumed. [1467] linearizable — Every operation behaves as though it took effect at one real instant visible to all observers. Use it rarely, but mean it fully. Authority, trust, and named shadows [1017] least privilege — Give only the authority required for the present act, no more. It is one of the simplest words for reducing future regret. [0978] authorization — After identity is known, what acts are permitted? Shadow: accidental omnipotence hidden behind a successful login. [0976] authenticate — Prove who is making the claim before deciding what the claimant may do. Shadow: trusting names that have not earned entrance. [1050] signature — Identity or intent made checkable through cryptographic proof. Useful wherever trust must survive distance and replay. [1007] hash — Arbitrary input reduced to a fixed fingerprint. Use it for identity, integrity, bucketing, and change detection; never mistake it for secrecy. [1028] policy — The declared rule by which a class of cases is decided. Good policy reduces arbitrary judgment; bad policy merely freezes confusion. [1561] race — An ordering curse: outcomes depend on timing you do not actually control. Name the race and the system becomes debuggable again. [1546] leak — Something escapes the boundary that should have held it: memory, secrets, file descriptors, authority, abstraction, or time. [1567] schema drift — The stored world and the assumed world have silently stopped matching. This is how migrations keep hurting after everyone thinks they are done. [1564] retry storm — Recovery logic amplifying failure instead of containing it. Unguided retries can turn a partial outage into a self-made siege. VI. Pocket Lexicon of 300 High-Force Runes The entries below preserve the master sigil numbering while keeping only the most reusable words. Read by house when you want a local vocabulary. Read by sigil when you want a stable reference against the full grimoire. Architecture, Abstraction, and Design · 0001-0112 Seams, layers, interfaces, models, and the shape of responsibility. [0001] abstraction — Deliberate forgetting of detail so larger structure can be reasoned about cleanly. [0002] adapter — A translator between unlike shapes that lets systems meet without infecting one another. [0005] anti-corruption layer — A protective seam that keeps one model from polluting another. [0006] API gateway — An edge threshold that centralizes entry, policy, and routing. [0012] boundary — The line where one responsibility ends and another begins. [0013] bounded context — A semantic fence: the same term is not forced to mean the same thing everywhere. [0023] component — A bounded unit of responsibility inside a larger design. [0030] coupling — The hidden tax paid when change in one place forces change elsewhere. [0034] dependency inversion — Stable policy should not kneel before unstable detail. [0036] domain model — The conceptual map of the business world the software is trying to serve. [0043] facade — A simplified front door hiding a messier interior. [0055] interface — A disciplined seam that lets unlike bodies cooperate without swapping internal organs. [0058] layer — A stratum with a narrow job and limited allowed dependencies. [0065] middleware — Cross-cutting logic placed in the path between request and handler. [0066] module — A package of related definitions meant to travel as one thing. [0071] orchestrator — A coordinator that sequences many services or tasks into one larger procedure. [0075] plugin — An extension point that lets capability be added without rewriting the host. [0082] proxy — A stand-in that speaks or receives on behalf of another body. [0092] service — A stable capability exposed for repeated use by others. [0098] source of truth — The place other copies are supposed to agree with. [0101] state machine — Behavior expressed as named states and legal transitions. Language, Semantics, and Formal Shape · 0113-0249 How software means before it runs: syntax, type, parsing, compilation. [0120] AST — The tree form of parsed program structure. [0124] borrow checker — A checker that enforces safe borrowing and lifetime law before runtime. [0132] compile-time — Known and fixed before execution begins. [0133] compiler — The translator from source language to lower-level executable form. [0158] generic — One definition parameterized over many concrete types or cases. [0159] grammar — The rules that say what strings count as well-formed structure. [0166] inference — Recovering missing type or shape information from surrounding evidence. [0171] interpreter — A runtime that executes a representation rather than precompiling it away. [0172] IR — An internal representation built for analysis and transformation. [0177] linker — The binder that turns compiled pieces into one loadable whole. [0180] macro — Code that writes or reshapes code. [0188] namespace — A naming region that prevents collisions and clarifies ownership. [0197] parser — The mechanism that turns surface text into structured meaning. [0200] polymorphism — One interface, many concrete behaviors. [0218] semantics — What a program means, not just how it is spelled. [0229] syntax — The legal surface form of the language. [0236] type — A declared or inferred class of values and allowed operations. [0240] typechecker — The checker that enforces type law before execution. Data, State, and Representation · 0250-0371 The shapes in which meaning is stored, moved, and compared. [0252] array — A contiguous ordered collection accessed by position. [0263] buffer — A temporary holding area used to smooth movement, parsing, or I/O. [0268] checksum — A compact fingerprint used to detect accidental change. [0272] config — Declared settings that shape behavior without editing code. [0280] cursor — A movable pointer into a sequence or result set. [0288] dictionary — Keyed lookup structure for named values. [0294] entity — A thing with stable identity that the system cares about. [0297] event — A record of something that happened. [0298] event log — History stored as events instead of overwritten final state. [0306] hash — A condensed fingerprint used for lookup, bucketing, or integrity checks. [0310] index — An access structure that trades space and write cost for faster reads. [0315] key — The field by which something is found or grouped. [0320] map — Associative collection from keys to values. [0322] message — A discrete packet of meaning sent between parts. [0338] record — A row-like bundle of named fields describing one thing. [0347] schema — The declared shape of stored meaning. [0356] snapshot — A captured view of state at one moment. [0359] state — The currently true condition of a thing that can change over time. Transformation, Algorithms, and Working Verbs · 0372-0511 The actions that turn one shape into another. [0395] decode — Turn encoded bytes or symbols back into usable meaning. [0402] deserialize — Rebuild structured state from a stored or transmitted form. [0404] diff — Make change visible by showing one state against another. [0410] encode — Turn meaning into a transportable or storable representation. [0417] extract — Pull the needed part out of a larger body. [0419] filter — Keep what matches; discard what does not. [0424] generate — Produce new structure, code, or data from rules or inputs. [0428] hydrate — Reattach lightweight structure to a previously transferred shell. [0438] link — Bind separate pieces into one connected whole. [0440] marshal — Pack structured state into a transportable form. [0441] materialize — Force a deferred or virtual thing into concrete existence. [0444] merge — Combine many lines or branches into one resolved form. [0445] migrate — Move shape, meaning, or state from one regime to another. [0448] normalize — Force many possible surfaces into one agreed shape. [0449] optimize — Trade time, space, or simplicity to improve a measured objective. [0453] partition — Turn raw text into structured representation. [0461] quantize — Change structure to improve clarity while preserving behavior. [0489] smooth — Write structured state into bytes, text, or wire form. [0496] synthesize — Change form, order, or representation while preserving some intended substance. [0510] verify — Demand evidence that a claim or result actually holds. Control Flow, Coordination, and Temporal Logic · 0512-0608 Time, waiting, ordering, retries, and concurrency. [0514] async — Work may proceed without immediate blocking at the call site. [0515] await — Pause until an asynchronous result becomes ready. [0516] backoff — Wait longer between retries so recovery does not become attack. [0517] barrier — A synchronization point no participant may cross early. [0527] circuit breaker — Trip open after repeated failure to prevent repeated harm. [0530] coroutine — A suspendable routine that can yield and later resume. [0539] enqueue — Place work onto a queue for later handling. [0540] event loop — The scheduler that drives nonblocking tasks and callbacks. [0546] flow control — Mechanisms that keep producers from outrunning consumers. [0549] future — A placeholder for a value that will exist later. [0561] mutex — Mutual exclusion for one critical region at a time. [0571] queue — Ordered holding area that decouples production from consumption. [0576] retry — Try again under policy rather than treating one failure as final. [0579] schedule — Assign work to time, order, or execution slots. [0581] semaphore — A counted gate controlling concurrent access to limited capacity. [0584] signal — Emit a condition change another task may respond to. [0598] timeout — A declared limit on how long uncertainty may persist. [0608] yield — Give up control now so another act may proceed. Runtime, Memory, and Execution · 0609-0684 Where code lives while running and what it costs to keep it alive. [0611] allocation — Reserve memory for something that is about to live. [0615] cache — Keep likely things close so repeated access costs less. [0621] copy-on-write — Share until mutation forces a real duplicate. [0631] garbage collection — Automatic reclamation of memory no longer reachable. [0634] heap — Region for dynamically allocated objects. [0636] hot path — The path where small inefficiencies burn real time. [0643] lifetime — How long a value may legally remain alive. [0645] locality — The performance dividend from keeping related data physically close. [0649] memory barrier — An ordering fence for memory effects across threads or cores. [0652] memory safety — Protection against illegal memory access and corruption. [0657] pinning — Keep an object fixed in place so other machinery can safely refer to it. [0663] reference count — Ownership tracked by counting how many references remain. [0670] stack — Region for call frames and short-lived local state. [0684] zero-copy — Move data without making redundant copies. Systems Programming and Operating-System Words · 0685-0770 Kernel surfaces, files, processes, descriptors, and host bargains. [0688] cgroup — A kernel mechanism for bounding resources by group. [0696] driver — Software that speaks directly to a device or kernel surface. [0697] epoll — Linux event notification for many file descriptors at once. [0700] file — A named persistent byte stream in a filesystem. [0701] file descriptor — A small integer handle standing in for an open kernel object. [0709] inode — Filesystem record describing a file apart from its name. [0714] kernel — The privileged core that arbitrates process, memory, and device access. [0720] mount — Attach a filesystem into the visible path tree. [0729] pipe — A byte stream connecting one process to another. [0732] process — A running program with its own address space and resources. [0755] syscall — The controlled crossing from userland into kernel service. [0760] thread — An independently schedulable line of execution inside a process. Networking and Distributed Systems · 0771-0886 Distance, coordination, consensus, routing, and failure across nodes. [0778] backpressure — Push resistance upstream when demand outruns capacity. [0791] consensus — Agreement protocol for shared truth across unreliable nodes. [0799] DNS — Translate names into network-reachable locations. [0804] endpoint — A callable boundary where a service can be reached. [0805] eventual consistency — Agreement postponed rather than denied. [0806] failover — Shift responsibility to a surviving node or path after failure. [0815] handshake — Opening ritual that establishes trust, parameters, or session state. [0819] HTTP — The dominant request-response protocol of the web. [0822] ingress — Traffic entering a service boundary. [0825] latency — The delay before useful work reaches the caller. [0828] load balancer — Distribute incoming work across many backends. [0834] mTLS — Mutual certificate-based identity proof on both sides of a connection. [0837] network partition — A split network that makes one cluster behave like several worlds. [0848] quorum — Enough agreement to act without requiring unanimity. [0852] replica — A copy kept elsewhere for durability, scale, or locality. [0859] route — The chosen path by which traffic should travel. [0862] RPC — Invoke remote behavior as though it were local, with all the risks that implies. [0870] socket — A network communication endpoint bound to protocol and address. [0876] TCP — Ordered reliable stream transport with congestion control. [0884] webhook — An outbound callback triggered by an event. Databases, Persistence, and Time-Binding Words · 0887-0968 Stored truth, transactional law, indexes, migration, and rollback. [0887] ACID — The classic four-part law of transactional storage: atomicity, consistency, isolation, durability. [0892] backup — A restorable copy taken so loss is not final. [0898] commit — Make a proposed change durable history. [0901] constraint — A rule the data is not allowed to violate. [0916] foreign key — A declared reference from one table to another table’s key. [0918] index — An access structure that speeds reads by paying extra write and space cost. [0921] isolation level — The degree to which concurrent transactions are allowed to see one another’s motion. [0925] materialized view — A stored query result traded for cheaper future reads. [0926] migration — Change stored reality without losing it. [0927] MVCC — Versioned rows that let readers and writers coexist more safely. [0933] primary key — The key that uniquely names one row inside its table. [0934] query plan — The strategy the database chose to answer the query. [0943] rollback — Retreat toward a previously trusted state. [0948] schema — The declared shape of database truth. [0959] transaction — A unit of work meant to stand or fall together. [0966] WAL — Write-ahead log: history recorded before dirty pages reach their final home. Security, Trust, and Warding Words · 0969-1063 Identity, permission, secrecy, integrity, and defensive boundaries. [0974] attestation — Evidence that a thing is what it claims to be or was produced the way it claims. [0976] authenticate — Prove who is making the claim. [0978] authorization — Decide what an already identified actor may do. [0990] code signing — Cryptographically bind an artifact to a trusted producer. [0998] defense in depth — Stack multiple protective layers so one failure is not total failure. [1002] encrypt — Make plaintext unreadable without the right key. [1007] hash — Reduce arbitrary input to a fixed fingerprint. [1012] integrity — Confidence that data has not been silently altered. [1014] key — The secret or public material that makes cryptographic operations possible. [1016] key rotation — Replace active keys before age or compromise turns them rotten. [1017] least privilege — Grant only the authority required for the present act. [1028] policy — A declared rule for how a class of cases is decided. [1037] revocation — The act of withdrawing trust from credentials or keys. [1042] sandbox — Constrain code inside a smaller, safer prison. [1044] secret — Information whose power comes from staying hidden. [1050] signature — Identity or intent made checkable through cryptographic proof. [1054] threat model — A structured view of likely attackers, assets, and failure paths. [1063] zero trust — Assume no network location or ambient context deserves automatic trust. Build, Tooling, Versioning, and Release · 1064-1139 How software is assembled, tracked, tested, and shipped. [1064] artifact — A produced thing you can store, ship, or compare. [1068] branch — A line of history where change can proceed without touching the main trunk. [1069] build — Turn source into a runnable or shippable artifact. [1073] canary — A small production release meant to detect reality before full rollout. [1076] CI — Continuous integration: change is merged only after automated checks speak. [1078] commit — Record a change as one named point in history. [1084] dependency — Something your code needs in order to build or run. [1086] deploy — Cross the line from forge to world. [1088] diff — A visible account of what changed between states. [1093] feature flag — A runtime switch that separates deploy from release. [1102] lockfile — The file that freezes dependency resolution into repeatable history. [1104] merge — Reconcile divergent lines of history into one. [1111] pipeline — The ordered automation that turns edit into tested artifact. [1117] release — A named version intended for actual users. [1120] reproducible build — A build that can be rebuilt into the same bits again. [1123] rollback — Operational permission to retreat after release. Testing, Verification, and Observability · 1140-1210 Evidence surfaces: tests, metrics, traces, profilers, and invariants. [1141] alert — A threshold that wakes humans or automation when evidence crosses concern. [1146] benchmark — Force a performance claim to meet measurement. [1152] contract test — A promise checked at the seam between systems. [1163] fuzzing — Throw weird inputs at the system until hidden assumptions break. [1171] integration test — Test that multiple real parts cooperate correctly together. [1172] invariant — A law that must remain true while the rest of the system moves. [1174] log — A recorded stream of events or decisions for later reading. [1176] metric — A numeric measure that can be tracked over time. [1180] observability — Enough evidence exists to infer what the system is doing from the outside. [1184] profiler — A measurement tool that reveals where time or allocation is being spent. [1186] property-based test — Test the law across many generated cases instead of one remembered example. [1187] regression test — A test written so yesterday’s bug does not return tomorrow. [1192] smoke test — A fast confidence check that the basic path still breathes. [1202] telemetry — Measurements emitted in a form other systems can store and alert on. [1204] trace — A preserved path through execution. [1207] unit test — Test the smallest meaningful unit in isolation. Hardware, Embedded, and Performance-Near Words · 1211-1290 When software starts bargaining with silicon, buses, timing, and heat. [1215] atomic instruction — An indivisible machine operation at instruction level. [1224] cache line — The coherence-sized chunk of cached memory; too much sharing here hurts. [1231] DMA — Direct memory access: device moves bytes without making the CPU do every step. [1235] endianness — The byte order in which multi-byte values are laid out. [1237] firmware — Software that is closer to the board than the application. [1243] GPU — A massively parallel processor built for throughput-heavy workloads. [1251] ISA — Instruction set architecture: the machine contract visible to software. [1255] latency budget — The maximum delay the system is allowed to spend and still remain acceptable. [1269] register — A tiny named storage cell inside the processor. [1276] SIMD — One instruction operating across many data lanes at once. [1281] throughput — How much useful work passes through in bounded time. [1285] utilization — The fraction of available capacity actually being used. [1287] volatile — A promise to the compiler that this value may change through unusual means. [1290] zero-copy — Near-metal data movement without redundant duplication. Interface, UX, and Human-Facing Words · 1291-1350 The names that shape attention, action, feedback, and usability. [1291] accessibility — Make the system usable by people with varied bodies, senses, and tools. [1293] affordance — A cue that suggests what action is possible here. [1303] discoverability — How easily a user can find what the system can do. [1306] feedback — The system speaking back after the user acts. [1308] form validation — Validation at the form boundary so bad input is caught legibly. [1317] keyboard navigation — Make the interface fully operable without a mouse. [1331] progressive disclosure — Reveal complexity in stages rather than all at once. [1333] responsive design — Layout that adapts gracefully to device or viewport size. [1346] user flow — The path a user walks through the product to finish a task. [1350] visual hierarchy — Arrange attention so the right thing is seen first. Promptcraft, AI-Oriented Engineering, and Spell Structure · 1351-1420 Role, context, retrieval, verification, tools, and prompt form. [1351] agent — A named locus of initiative that may observe, decide, and invoke tools. [1358] constraint — A bound that removes degrees of freedom in favor of correctness. [1359] context — The surrounding facts that give the prompt its force. [1364] evaluation — The act of measuring whether the model is actually useful. [1373] grounding — Tie generation to evidence instead of to free-association alone. [1374] guardrail — A boundary that narrows allowed behavior without fully specifying the answer. [1382] objective — The outcome the spell is trying to cause. [1383] output contract — The required shape the answer must take. [1389] prompt — The surface instruction that biases a model toward task, role, and style. [1395] retrieval — Bring external evidence into the model’s working context. [1405] spell — A structured instruction artifact that binds role, goal, context, and checks. [1409] system prompt — The highest-order framing instruction in the conversation. [1414] tool call — A step where the model reaches beyond text into external action. [1419] verification — Truth-checking added to output generation. Guarantee Words and Quality Attributes · 1421-1512 The adjectives that claim durable behavioral law. [1425] atomic — No halfway state is allowed to leak. [1429] available — Reachable and functioning when needed. [1430] backward-compatible — New versions do not casually break old clients or data. [1437] composable — Small parts combine without excessive friction. [1440] consistent — Different observers are not being told incompatible stories. [1442] crash-safe — Failure does not leave storage in nonsense. [1445] deterministic — Same inputs, same result. [1446] durable — Once acknowledged, the change really sticks. [1461] idempotent — Same request, same lasting effect. [1462] immutable — Written once, then never changed in place. [1467] linearizable — Behaves as though each operation took effect at one visible instant. [1471] maintainable — Cheap enough to understand, modify, and keep healthy. [1472] memory-safe — Will not casually trespass across allocation boundaries. [1474] observable — Structured so internal behavior can be inferred from external evidence. [1481] pure — Same inputs, same output, no hidden side effects. [1484] reliable — Keeps doing the promised thing under ordinary stress. [1485] reproducible — Can be rebuilt or rerun and yield the same result again. [1490] scalable — Can grow without collapsing the qualities that matter. [1492] serializable — Concurrency behaves as though transactions happened in one clean order. Failure Words, Pathologies, and Counter-Spells · 1513-1582 The names engineers use when systems lie, stall, diverge, or collapse. [1517] cascading failure — One failure fans out into many dependent failures. [1520] contention — Too many actors fighting for the same scarce resource. [1521] corruption — Stored or transmitted truth damaged into falsehood. [1525] deadlock — Two or more actors wait on one another forever. [1529] dependency hell — Transitive requirements turning ordinary change into a trap. [1531] drift — Slow departure from the world you thought you were still in. [1534] exhaustion — The resource is simply used up. [1537] flapping — Rapid unhealthy oscillation between states. [1542] inconsistent read — A read that sees a world that never really existed as one coherent moment. [1546] leak — Something escapes the boundary that should have held it. [1547] livelock — Everyone keeps moving but nobody makes progress. [1548] lost update — One writer quietly stomps another writer’s valid change. [1554] outage — Service unavailable where availability was expected. [1555] overflow — Value exceeds the representable range. [1558] partial failure — Some of the system failed while the rest kept limping. [1561] race — Outcome depends on timing you do not actually control. [1562] regression — A previously solved bug or quality loss has returned. [1564] retry storm — Recovery logic amplifying failure instead of containing it. [1567] schema drift — Stored shape and assumed shape have silently diverged. [1568] split-brain — Separated leaders each believe they are authoritative. Naming Runes, Affixes, and Compound Forms · 1583-1645 The modifiers that quietly shift design intent when attached to other words. [1584] -aware — Marks that something notices the surrounding condition it names. [1588] -driven — Signals that behavior is organized around events or causes. [1589] -first — Declares priority or design center: security-first, API-first, offline-first. [1598] -safe — Asserts a protected behavior such as memory-safe or thread-safe. [1605] API-first — Design the interface surface before the implementations behind it. [1606] append-only — History grows by addition rather than mutation. [1613] crash-only — Only live briefly, start fast, and recover by restart rather than repair. [1616] default-deny — Access is forbidden unless explicitly granted. [1618] event-driven — Action propagates from events rather than from direct polling or command loops. [1620] fail-fast — Abort early when assumptions break instead of smearing damage forward. [1623] infrastructure-as-code — Operational change expressed as reviewable source. [1626] machine-readable — Structured so software, not only humans, can read it reliably. [1631] offline-first — Designed to keep working with poor or absent connectivity. [1632] policy-as-code — Policy declared as versioned, testable code. [1639] single source of truth — One canonical place others are expected to mirror. [1644] zero-downtime — Change introduced without taking the service dark. Closing Note A normal software word names. A strong software word constrains, invokes, protects, or exposes. A spell is what happens when such words are arranged so that a human or machine can act on them with less waste and less self-deception. Carry this field edition until the best words start appearing earlier: in the prompt before the code, in the invariant before the patch, in the rollback plan before the migration, in the measurement before the optimization, in the policy before the permission, in the shadow before the outage. That is the whole art: not making software mystical, but noticing that software has always been ruled by names with force.

Pocket edition compiled from the public-release grimoire for daily use in AI-assisted software engineering. addendum on stacks Addendum I On Stacked Spells Queues, Loops, and Recursive Rituals for Software Spellcraft A companion to Software Magic Grimoire v1 and Pocket Grimoire: Software Spellcraft Version 1.0 · March 2026 Abstract The original grimoire defines the spell as the basic unit of software-operative language. This addendum introduces the spell stack: a named, reusable queue of spells cast in stable order with explicit handoffs, guards, and termination rules. Spell stacks are the missing middle layer between a single prompt and a full engineering campaign. They explain why competent AI-assisted software work rarely comes from one giant incantation. Real work alternates between discovery, design, generation, verification, repair, release, and rollback readiness. Stacks encode those alternations. This addendum defines stack structure, laws, notation, and composite seals, then gives examples of linear, guarded, looped, and recursive stacks. Looped stacks repeat until a measurable exit condition is satisfied. Recursive stacks call themselves on smaller scopes until a base case is reached. Together they extend the spell system from isolated prompts to reproducible multi-step operations. A spell chooses a mode of action; a stack chooses an order of operations. I. Why Stacks Exist A single spell can be powerful, but software work almost never stays in one cognitive mode for long. The same task may begin with discovery, pass into design, descend into implementation, halt for verification, and then branch into repair or release. When all of those modes are packed into one giant prompt, the model is asked to reason, decide, generate, critique, and certify all at once. That usually produces mush: too much breadth, too little accountability, and no obvious place to inspect failure. Spell stacks solve this by turning one large wish into a named procession of smaller casts. Each spell in the sequence has a job, an artifact to hand forward, and a condition that authorizes the next move. In ordinary engineering language, a stack is part playbook, part pipeline, part queue, part review discipline. In grimoire language, it is a repeatable choreography of force. The common case is simple: first this spell, then that one. But once the pattern is made explicit, richer forms appear naturally. Some sequences wait on guards. Some loop until a measurement clears a threshold. Some recurse into smaller scopes. Some are made of whole sub-stacks rather than single spells. Stacks are to spells what procedures are to statements, what release trains are to single commands, and what incident playbooks are to individual instincts. II. Definitions The terminology below makes spell stacks precise without draining them of usability. Term Meaning Spell A bounded operative instruction. In the grimoire, a spell is usually expressed through the limbs of role, objective, context, constraints, procedure, output, verification, and failure behavior. Spell stack A named, reusable queue of spells cast in stable order. A stack includes handoffs, guards, and explicit entry and exit rules. Stack frame One invocation of one spell inside a stack, together with the local artifacts and state it receives. Handoff artifact The concrete output passed from one spell to the next: a plan, a patch, a failing test, a metrics snapshot, a schema diff, an evidence bundle. Guard A condition that must be satisfied before the next spell may fire. Guards are usually verification, parity, approval, or threshold checks. Loop A substack that repeats on the same scope until a measurable exit condition is met. Recursion A stack that calls itself on smaller scope until a base case is reached. Recovery path The spell or substack invoked when the main line fails, stalls, or violates a guard. Despite the name, most spell stacks behave like queues in time: first cast, first handoff, next cast. They are called stacks because the spells accumulate, may nest, and may themselves be composed into higher-order structures. So the image is layered; the execution is usually sequential. III. Relation to the Existing System Spell stacks do not replace the spell. They sit above it. The individual spell remains the atomic unit of force; the stack is the reusable choreography that binds several spells into one operation. 1. Limbs are preserved. Each spell in a stack still carries whatever limbs it needs. Some frames are fast casts with only role, objective, context, and verify; others are full rituals with all eight limbs. 2. Cast levels become local. A single stack may contain minor casts for drafting, working casts for generation, and ritual casts for verification, migration, or release gating. 3. Sigils become composite. If a spell has a canonical form, then a stack has one too: an ordered composition of spell seals, transition operators, entry conditions, exit rules, and recovery paths. 4. Coils gain time. The coil diagram inspects the internal geometry of one spell. A stack can be thought of as a procession or braid of such coils through time. Repeated transitions become stable paths; loops create re-entry arcs; recursion creates nested descent. 5. The canon becomes operational. The lexicon lists words of force. Stacks are where those words are repeatedly made to work together: reproduce, instrument, patch, verify; expand, backfill, compare, cut over, rollback. A compact formalization is useful: Let a spell be Sigma = (R, O, C, K, P, U, V, F), where omitted limbs are simply left blank in a lighter cast. Then a stack T may be written as: T = (E, Sigma1, tau1, Sigma2, tau2, … , tau(n-1), Sigman, X, Q) E = entry condition tau_i = transition rule or guard between spells X = exit condition Q = recovery map or failure path IV. Stack Grammar and Notation A practical stack template should be readable by humans, castable by AI systems, and cleanly canonicalized for tooling. STACK v ENTER: IN: 1. [minor|working|ritual] OUT: ADVANCE WHEN: 2. [cast level] OUT: ADVANCE WHEN: LOOP <steps a..b> UNTIL # optional CALL () # optional ON FAIL -> # optional EXIT: Useful control operators: Operator Meaning Typical use -> Then / hand off Move from one spell to the next after the stated artifact is produced. [guard] Gate before advance Require tests, approval, parity, or threshold checks before the next step. LOOP Repeat substack Use for debugging, optimization, repair, and parity verification. CALL Recursive descent Invoke the same stack on a smaller module, service, file, or decision scope. ON FAIL Recovery path Rollback, escalate, preserve evidence, or switch to a repair stack. V. The Laws of Stackcraft 1. Separate incompatible modes. Do not ask the same spell to discover facts, design the solution, implement code, and certify safety all at once. 2. Make every handoff concrete. A stack should pass artifacts, not vibes. Plans, diffs, traces, tests, and parity reports are better than vague summaries. 3. Name the gate between spells. Every meaningful transition should say what authorizes the next step. 4. Verify before irreversible action. Cutovers, deletes, merges, and releases should not happen on the same breath that invented them. 5. Loop on evidence, not on hope. A repeated substack must name the metric or observation that tells you whether progress is real. 6. Recurse only when scope narrows. If a recursive call is not moving to a smaller or simpler problem, it is not recursion; it is wandering. 7. Keep recovery nearby. Risky stacks should define rollback, escalation, or evidence-preservation spells before anything goes wrong. 8. Version repeated stacks. Once a choreography is reused, give it a name, a version, and a canonical seal. VI. Canonical Forms Most practical stacks fall into a small set of recurring shapes. Form Shape Best for Primary hazard Linear A fixed queue of spells. Release, onboarding, migration, checklists. Hidden assumptions between steps. Guarded A queue with explicit gates. Risky actions, deploys, schema changes. Skipping the gate under time pressure. Branched A queue that chooses from a few next spells. Triage, incident routing, support diagnosis. Branch explosion. Looped A repeated substack on the same scope. Debugging, optimization, repair. Infinite spin without measurable progress. Recursive The same stack called on smaller scope. Large refactors, subsystem design, tree search. No base case or no scope reduction. Macro-stack A stack made of named sub-stacks. Feature delivery, incident programs, agentic workflows. Process bloat. Figure 1. Canonical spell stack forms. Linear stacks dominate ordinary work. Looped and recursive forms are advanced but extremely powerful when their exit rules are explicit. VII. Looped Stacks and Recursive Stacks These two advanced forms are related but not identical. A loop revisits the same problem at the same level with improved evidence. Recursion descends into a smaller problem and then returns upward. Question Looped stack Recursive stack What repeats? A substack on the same scope. The whole stack on smaller scope. What changes each pass? Evidence, metrics, patch candidate, test state. Problem size, module boundary, search depth. What ends it? A measurable exit condition or attempt budget. A base case: small enough scope, solved leaf, or maximum depth. Typical use Bug repair, performance tuning, backfill verification. Large refactors, subsystem decomposition, agentic planning trees. Failure mode Spin without progress. Explode in depth or lose contract consistency. The two can be combined. A recursive implementation stack may descend into smaller modules, while each leaf module uses a looped build-test-repair stack until its local verification passes. VIII. Worked Spell Stacks The examples below are intentionally practical. Each one names the queue, the handoff logic, and the exit rule. These are not the only valid stacks, but they are strong default choreographies for common software work. 1. Code Generation and Repair Loop Use when an AI system is helping write or modify software and you want generation to stay tied to real execution evidence. ## Spell Artifact and advance rule 1 Specify Emit a precise task statement, constraints, interfaces, and non-goals. Advance when the target is testable. 2 Draft Produce the smallest plausible implementation or patch. Advance when the code compiles in principle and names assumptions. 3 Run Execute build, tests, linters, or type checks. Advance when the actual failures are captured verbatim. 4 Diagnose Interpret failures using only the emitted evidence. Advance when the likely cause and repair surface are stated. 5 Repair Apply the smallest diff that addresses the diagnosed cause. Advance when the patch is explicit. 6 Verify Re-run checks and summarize residual risk. Advance when the exit condition holds. Loop rule: Repeat steps 3 through 6 until the checks pass, the error surface stabilizes without progress, or the attempt budget is exhausted. On fail: Escalate with the full evidence bundle: spec, code diff, failing output, diagnostic notes, and unresolved assumptions. Why it works: It separates invention from judgment. The model is allowed to generate code, but only a later spell is allowed to interpret the results. 2. Bug-Hunt Stack Use when a defect is real but the cause is not yet localized. ## Spell Artifact and advance rule 1 Reproduce Create or tighten a stable reproduction. Advance when the failure can be triggered on demand. 2 Localize Narrow the suspect surface to component, file, feature flag, or request path. Advance when the search field is smaller. 3 Instrument Add logging, traces, asserts, or counters. Advance when new evidence can distinguish hypotheses. 4 Hypothesize State the likely failure mechanism and the smallest repair surface. 5 Patch Apply the minimal change that addresses the current hypothesis. 6 Verify Confirm the defect is gone and run a regression sweep on neighboring behavior. Loop rule: Repeat steps 2 through 6 until the bug is eliminated or the evidence stops improving. On fail: Escalate to a deeper diagnostic stack; preserve the reproduction, traces, and last rejected hypotheses. Why it works: The stack prevents the classic failure mode of patching before localization. 3. Safe Refactor Stack Use when the code structure must improve without changing externally visible behavior. ## Spell Artifact and advance rule 1 Freeze invariants Name what must not change: API behavior, outputs, performance envelope, data semantics. 2 Characterize Write or collect tests that pin current behavior. 3 Reshape Extract, rename, split, or simplify structure. 4 Static verify Run type checks, linters, and architecture rules. 5 Behavior verify Run characterization tests and inspect semantic diffs. 6 Review Look for leaky abstractions, drift, or renamed confusion before merge. Loop rule: Repeat steps 3 through 5 until the desired structure is reached without invariant breakage. On fail: Revert to the last green state and restate the invariants more precisely. Why it works: It puts behavioral contracts in front of structural ambition. 4. Live Migration Stack Use when data, schemas, or infrastructure are changing in a live environment. ## Spell Artifact and advance rule 1 Inventory Map the moving parts, dependencies, rollback boundary, and blast radius. 2 Prepare rollback Take backups, snapshots, feature flags, or dual-read capability. Advance only when reversal is real. 3 Expand compatibly Add the new structure in a backward-compatible form. 4 Backfill Populate the new representation without cutting off the old one. 5 Compare parity Measure whether old and new paths agree on real traffic or replayed fixtures. 6 Cut over Switch reads or writes only after parity holds and rollback is live. 7 Observe Monitor errors, latency, drift, and rollback triggers during the live window. 8 Contract Remove old paths after the safety window closes. Loop rule: Repeat parity checks and observation windows until confidence is sufficient for cutover and contraction. On fail: Rollback immediately using the prepared boundary; preserve divergence samples for the postmortem. Why it works: The stack forces reversibility to exist before forward motion becomes expensive. 5. Release Gate Stack Use when a change set is already built and the question is whether it is ready to ship. ## Spell Artifact and advance rule 1 Assemble candidate Freeze the release artifact and the exact config that will ship. 2 Quality gate Run tests, static checks, dependency scans, and rollout prerequisites. 3 Stage deploy Ship to a staging or canary environment. 4 Observe Inspect metrics, logs, traces, dashboards, and user-critical flows. 5 Promote or rollback Advance to broad release only if the guard remains green. On fail: Rollback the candidate and open a repair stack instead of arguing from hope. Why it works: This is the shortest stack in the set, but it is one of the most important because it resists shipping by narrative alone. 6. Recursive Decomposition Stack Use when the task is too large for one spell or one session: a subsystem rewrite, a multi-package extraction, or an agentic planning tree. The trick is to recurse only while the scope is truly shrinking. STACK Implement-Subsystem(scope) ENTER: scope is too large, risky, or entangled for a one-pass spell IF scope <= base_case: CAST Design-Implement-Verify(scope) RETURN CAST Define-Contract(scope) CAST Split-Into-Children(scope) FOR child IN children(scope): CALL Implement-Subsystem(child) CAST Integrate(scope) CAST System-Verify(scope) EXIT: children are green and the parent contract still holds Base case: a scope small enough to be understood, implemented, and verified in one bounded pass. Primary hazard: fake recursion. If each descent merely renames the same giant problem, the stack will grow without solving anything. Why it works: it lets one named choreography operate at several scales while preserving contracts at every boundary. A higher-order example: macro-stacks Stacks can themselves be queued. A feature-delivery campaign, for example, can be modeled as: Discovery Stack -> Design Stack -> Build Stack -> Verification Stack -> Release Stack That is a stack made of named sub-stacks rather than leaf spells. Once a team begins naming these macro-stacks, prompt practice starts to look less like ad hoc querying and more like versioned operational craft. IX. Canonicalization, Seals, and Numbering for Stacks Because the grimoire already defines canonical forms for individual spells, spell stacks can inherit the same discipline. A practical stack seal should be derived from a canonical stack stream. The stream should include, in order: the stack name and version, the entry condition, the ordered spell seals, the transition operators and guards between them, the exit rule, and the recovery path. Canonical stream example: STACK|CODE-REPAIR-LOOP|v1|ENTER:failing tests or precise spec|SPECIFY|THEN|DRAFT|THEN|RUN|THEN|DIAGNOSE|THEN|REPAIR|THEN|VERIFY|LOOP(3..6)|UNTIL:checks pass or budget exhausted|FAIL:escalate-with-evidence Formal sigil: Gödel-encode the canonical token stream. Working seal: derive a short digest from that same stream for everyday use. This keeps the theory and the practice aligned. The formal sigil provides exactness; the working seal provides usability. The numbers themselves may become astronomical, which is expected. In ordinary use, teams should handle the short seal, the name, and the version. The important part is that stack identity is determined by ordered choreography, not just by a title. X. Failure Modes of Stacks Monolithic relapse. A team names a stack but still hides most of the work in one bloated spell. Invisible handoffs. The next spell depends on information that was never emitted as an artifact. Gate skipping. A release, cutover, or merge advances without satisfying the stated guard. Spin loops. A loop repeats without a metric, a budget, or a way to tell whether progress occurred. Infinite descent. A recursive stack has no real base case or keeps re-creating the same scale of problem. Process bloat. A tiny task is forced through a heavyweight stack that costs more than it saves. Seal drift. The stack changes order or exit logic but keeps the old name and version, defeating reuse. XI. Closing Note The single spell remains the elemental unit of software-operative language. The spell stack is the next layer up: the point where isolated prompts become repeatable craft. Once a sequence of casts is used again and again in stable order, it deserves a name. Once it has a name, it can be versioned. Once it is versioned, it can be taught, compared, sealed, and improved. That is the purpose of stacked spells. They let teams stop pretending that software work happens in one breath. They give shape to the real rhythm of engineering: discover, define, generate, test, repair, verify, release, recover. Name the queue. Guard the transitions. Repeat only with evidence. Recurse only with a base case.

spellbook The First Edition Spellbook of Software Spellcraft Ready-made AI spells for real software work Leveled casts, stacked rituals, and reusable prompts for designing, building, debugging, testing, shipping, and repairing software with modern language models. A prompt is a temporary control surface for a reasoning system. A good spell gives that surface shape, law, and exit conditions. Edition 1.0 · March 2026 This book is meant to be used, not admired from a distance. Every spell inside is a copy-paste-ready prompt template for contemporary LLMs used in software work. Replace the bracketed placeholders with real artifacts from your task, keep the output contracts intact unless you know why you are changing them, and choose the cast level that matches the risk. These spells are built on the system developed in the larger grimoire, the pocket grimoire, and the addendum on stacked spells: * The spell is the atomic control surface. * The level determines how much structure, verification, and failure behavior you bind into the cast. * The stack is a reusable queue of spells cast in a known order. * The artifact is the thing one spell hands to the next. * The seal is the short reusable name for a spell family. * The stack seal names a repeated choreography. How to use this book 1. Choose the smallest cast that will safely do the job. Minor casts are fast. Working casts are the daily default. Ritual casts are for risky, expensive, or automatable work. 2. Feed artifacts, not vibes. Logs, diffs, schemas, traces, stack traces, tests, interfaces, migration plans, and benchmarks are better than summaries about them. 3. Separate invention from judgment. Do not ask the same cast to brainstorm, implement, verify, and certify all at once when the stakes are real. 4. Bind the output to a shape. Make the model return a bounded artifact: a spec card, a fault tree, a patch bundle, a migration runbook, a threat table, a review memo. 5. Keep the verification limb for risky work. Any spell that can touch production behavior, user data, system security, or team trust should define how success will be checked. 6. Use stacks when the work changes mode. Clarifying a request, designing a change, implementing it, testing it, and releasing it are different acts. Good stacks respect that. Cast levels Level I — Minor cast Use for fast thinking, low-stakes drafting, quick triage, and live conversation. Typical limbs: Role, Objective, Context, Verify. Level II — Working cast Use for daily engineering work, bounded artifact generation, code review, planning, and implementation. Typical limbs: Role, Objective, Context, Constraints, Output, Verify. Level III — Ritual cast Use for risky changes, migrations, production work, security-sensitive tasks, and automatable pipelines. Typical limbs: Role, Objective, Context, Constraints, Procedure, Output, Verify, Failure. A good rule of thumb: * Use Minor when you want a sharp answer or compact artifact. * Use Working when you want something you could actually carry into a PR, doc, issue, or terminal session. * Use Ritual when you would be embarrassed or endangered if the model improvised over an unstated edge case. Standard handoff artifacts * Spec Card — produced by DISTILL and consumed by DESIGN, FORGE, API, and DECOMPOSE. Contains objective, constraints, acceptance criteria, and open questions. * Design Brief — produced by DESIGN and consumed by FORGE, API, MIGRATE, and GATE. Contains the recommended approach, alternatives, interfaces, and risks. * Patch Bundle — produced by FORGE, PATCH, or REFACTOR and consumed by TEST and GATE. Contains the summary, assumptions, unified diff, test notes, and rollback note. * Fault Tree — produced by DIAGNOSE and consumed by PATCH, INCIDENT, TEST, and GATE. Contains observations, ranked hypotheses, confirming checks, and mitigations. * Verification Bundle — produced by TEST or OPTIMIZE and consumed by GATE and sometimes INCIDENT. Contains the test matrix, benchmark or check results, edge cases, and known gaps. * Contract Sheet — produced by API and consumed by FORGE, TEST, and GATE. Contains request and response shape, errors, auth model, versioning, and examples. * Migration Runbook — produced by MIGRATE and consumed by GATE and INCIDENT. Contains the step order, prechecks, cutover conditions, parity checks, and rollback plan. * Threat Table — produced by HARDEN and consumed by FORGE, PATCH, and GATE. Contains attack surfaces, findings, exploit paths, severity, and remediations. * Go/No-Go Memo — produced by GATE and consumed by humans or release automation. Contains blockers, missing evidence, rollout watchpoints, and the release recommendation. * Runbook / Operator Note — produced by SCRIBE and consumed by humans, on-call, onboarding, and future stacks. Contains how to run, observe, recover, and repair the system. * Work Tree — produced by DECOMPOSE and consumed by all leaf spell families. Contains bounded subtasks, dependencies, integration checkpoints, and exit conditions. Universal handoff stanza When moving from one spell to the next in a stack, prepend this small stanza before the next cast: Continue the stack.

Current cast: [SPELL.SEAL.LEVEL] Carry forward only validated facts from the prior artifact. Treat assumptions not yet verified as provisional. If the artifact is internally inconsistent, say so before proceeding.

Artifact: [PASTE PRIOR ARTIFACT HERE] Stack forms

Use these forms deliberately: * Linear stack — one pass, ordered handoff. * Gated stack — each transition requires evidence. * Looped stack — repeat the same local cycle until a measurable exit condition is met. * Recursive stack — reapply the same family of casts to smaller bounded units, then recompose against global invariants. A loop revisits the same problem with better evidence. A recursive stack descends into smaller problems and returns. Quick index by outcome * If you need to turn a rough request into a buildable target, cast DISTILL. It is often followed by DESIGN, FORGE, or DECOMPOSE. * If you need to choose an architecture or implementation shape, cast DESIGN. It is often followed by FORGE, API, or MIGRATE. * If you need to generate a bounded patch from a known target, cast FORGE. It is often followed by TEST and GATE. * If you need to find the cause of a failure, cast DIAGNOSE. It is often followed by PATCH, INCIDENT, or TEST. * If you need to make the smallest safe fix, cast PATCH. It is often followed by TEST and GATE. * If you need to improve structure without changing behavior, cast REFACTOR. It is often followed by TEST and GATE. * If you need to create or strengthen verification, cast TEST. It is often followed by GATE or another implementation spell. * If you need to design an external or internal contract, cast API. It is often followed by FORGE, TEST, and GATE. * If you need to change schema or move data safely, cast MIGRATE. It is often followed by TEST, GATE, and sometimes INCIDENT. * If you need to make a slow thing measurably faster, cast OPTIMIZE. It is often followed by FORGE, TEST, and GATE. * If you need to review security posture or patch a vulnerability, cast HARDEN. It is often followed by FORGE, PATCH, and GATE. * If you need to decide whether a change may ship, cast GATE. * If you need to operate through a live outage or degradation, cast INCIDENT. It is often followed by DIAGNOSE, PATCH, and SCRIBE. * If you need to produce durable docs or runbooks, cast SCRIBE. * If you need to break a large system into safe subproblems, cast DECOMPOSE. The techno-warlock architecture in practice The spellbook is easiest to use when the system is kept simple: * A spell is one bounded prompt with a job. * A seal is the reusable short name of a spell family. * A level tells you how much structure, verification, and failure behavior the cast should carry. * A handoff artifact is the structured output one spell passes to the next. * A stack is a queued sequence of spells reused in a known order. * A loop repeats a local substack until a measurable exit condition is met. * Recursion applies the same kind of casting to smaller bounded units and then recomposes the result against global invariants. * A gate is a named evidence threshold between stages.

The coil picture is not required for everyday use, but it is useful for inspection: a weak spell often breaks where distant clauses should agree. A patch that does not connect objective to verification, or procedure to constraints, may still sound clever while failing in practice. Adaptation rules When customizing these spells: 1. Replace bracketed placeholders with real artifacts. 2. Keep the output contract unless you have a reason to change it. 3. Add constraints that reflect real danger: public API stability, migrations, security, performance, compliance, release timing. 4. Remove ceremony only when the risk is truly low. 5. Never let a model certify a risky change without evidence. 6. If a spell produces mush, shorten the scope and strengthen the output contract. 7. If a spell becomes too long for a live conversation, split it into a stack. Common casting failures * Overstuffing — one cast asked to discover, design, implement, and certify all at once. * Artifact starvation — the model is asked to operate on a repo, bug, or migration it cannot actually see. * Soft outputs — the result sounds smart but does not return a usable artifact. * Verification theater — “looks good” language without real checks. * Scope bleed — a small requested change mutates into a redesign. * Safety collapse — no rollback, no blast-radius note, no release gate. * Loop drift — a repeated stack lacks a measurable exit condition. * Recursive blur — the stack descends into smaller pieces without preserving global invariants. The Core Spellbook DISTILL — Spell of Wish-to-Spec Transmutation Use when: Use when the ask is fuzzy, overloaded, or mixed with unstated assumptions. Input offering: Raw request, codebase or product context, constraints already known, relevant business or technical stakes. Handoff artifact: Spec Card Often followed by: DESIGN, FORGE, API, DECOMPOSE Operator note: This spell is how vague desire becomes a bounded engineering target. Its job is not to solve the problem yet; its job is to make the problem shapeable. DISTILL.M — Level I · Minor cast Fast, low-friction, and appropriate when the goal is sharp but the risk is low. You are acting as a senior software engineer who is good at turning fuzzy requests into buildable targets.

Turn the raw request below into a compact Spec Card.

Raw request: [PASTE REQUEST]

Context: [PASTE PRODUCT / CODEBASE / TEAM CONTEXT]

Known constraints: [PASTE CONSTRAINTS OR “none yet”]

Do the following: - restate the objective in one sentence - separate scope from non-goals - list assumptions you had to make - define success in testable terms - ask at most five missing questions, ordered by impact

Return exactly: 1. Objective 2. In-scope 3. Out-of-scope 4. Constraints 5. Acceptance criteria 6. Open questions DISTILL.W — Level II · Working cast The default daily cast: bounded, reviewable, and usually handoff-ready. You are acting as a product-minded staff engineer.

Convert the request below into an implementation-ready Spec Card for an AI-assisted software task.

Request: [PASTE REQUEST]

Context: [PASTE RELEVANT PRODUCT, SYSTEM, USER, OR CODEBASE CONTEXT]

Constraints: [PASTE TECHNICAL, BUSINESS, SECURITY, PERFORMANCE, OR TIME CONSTRAINTS]

Requirements for the Spec Card: - distinguish facts from assumptions - define who or what changes behavior after this work lands - state the smallest useful version of the change - state explicit non-goals to prevent scope creep - provide acceptance criteria that a test or reviewer could verify - identify the three highest-risk unknowns

Output contract: Return: 1. Objective 2. User / system effect 3. In-scope 4. Out-of-scope 5. Constraints 6. Assumptions 7. Acceptance criteria 8. Risky unknowns 9. Questions that must be answered before implementation

If the request is too underspecified to proceed safely, say that clearly and stop after section 9. DISTILL.R — Level III · Ritual cast For risky, expensive, or automatable work where verification and failure behavior matter. You are acting as a principal engineer preparing a production-grade software change for downstream design and implementation.

Build a rigorous Spec Card from the material below.

Request: [PASTE REQUEST]

Environment and system context: [PASTE ARCHITECTURE, DOMAIN, CODEBASE, OR OPERATING CONTEXT]

Hard constraints: [PASTE COMPATIBILITY, SECURITY, DATA, PERFORMANCE, COMPLIANCE, OR TIME CONSTRAINTS]

Procedure: 1. Extract stated facts. 2. Mark inferred assumptions separately. 3. Define the primary user or system outcome. 4. Define the smallest shippable scope. 5. Enumerate non-goals and excluded interpretations. 6. State invariants that must not be violated. 7. Define observable acceptance criteria. 8. Name edge cases and rollout concerns. 9. Identify what still must be learned before design or coding begins.

Output contract: Return a Spec Card with these sections: - Objective - Why now - Affected users / systems - In-scope behavior - Non-goals - Invariants to preserve - Constraints - Assumptions - Acceptance criteria - Edge cases - Rollout / observability concerns - Open questions - Recommended next spell

Verification: Acceptance criteria must be written so they could be translated into tests, checks, or review gates.

Failure behavior: If critical information is missing, do not invent it. Stop after Open questions and Recommended next spell. DESIGN — Spell of Architecture and Shape Use when: Use when the problem is clear enough to compare approaches but the implementation path is not yet chosen. Input offering: Spec Card, architecture context, interfaces, constraints, known risks. Handoff artifact: Design Brief Often followed by: FORGE, API, MIGRATE, GATE Operator note: This spell chooses shape. It is strongest when it is asked to compare alternatives and recommend one with reasons. DESIGN.M — Level I · Minor cast Fast, low-friction, and appropriate when the goal is sharp but the risk is low. You are acting as a pragmatic software architect.

Using the spec below, propose 2-3 implementation approaches and recommend one.

Spec Card: [PASTE SPEC CARD]

System context: [PASTE RELEVANT ARCHITECTURE OR CODEBASE CONTEXT]

Constraints: [PASTE CONSTRAINTS]

Return exactly: 1. Recommended approach 2. Alternative approaches 3. Why the recommendation wins here 4. Main risks 5. First implementation steps

Keep it concrete. No generic architecture sermonizing. DESIGN.W — Level II · Working cast The default daily cast: bounded, reviewable, and usually handoff-ready. You are acting as a principal software designer producing a Design Brief that an implementation spell can follow.

Inputs: - Spec Card: [PASTE SPEC CARD] - Architecture context: [PASTE SYSTEM CONTEXT] - Existing interfaces / data model notes: [PASTE IF AVAILABLE] - Constraints: [PASTE CONSTRAINTS]

Do the following: - compare up to three viable designs - recommend one design and explain the tradeoffs - identify component boundaries and interface changes - name data flow, failure modes, and observability implications - describe the safest implementation order

Output contract: Return: 1. Recommended design 2. Alternatives considered 3. Component / module boundaries 4. Interface or schema changes 5. Data flow summary 6. Main risks and failure modes 7. Implementation sequence 8. Verification hooks 9. Questions still open

Prefer the simplest design that satisfies the spec without painting the team into a corner. DESIGN.R — Level III · Ritual cast For risky, expensive, or automatable work where verification and failure behavior matter. You are acting as a staff-plus architect writing an ADR-ready Design Brief for a production software change.

Inputs: - Spec Card: [PASTE SPEC CARD] - Architecture and runtime context: [PASTE CONTEXT] - Existing contracts, schemas, or service boundaries: [PASTE IF AVAILABLE] - Hard constraints: [PASTE CONSTRAINTS]

Procedure: 1. Restate the design problem in one sentence. 2. Compare the leading viable approaches. 3. Recommend a design and justify it against constraints. 4. Define boundaries, contracts, and data movement. 5. Identify invariants the design must preserve. 6. Name failure modes, operational concerns, and migration costs. 7. Define implementation phases and rollback-friendly checkpoints. 8. Specify what must be measured or tested before release.

Output contract: Return an ADR-ready Design Brief with: - Problem statement - Recommended design - Alternatives and tradeoffs - Component boundaries - Interface / contract changes - Data model implications - Invariants to preserve - Failure modes and operational concerns - Implementation phases - Verification plan - Rollback / recovery considerations - Unresolved questions - Recommended next spell

Failure behavior: If the proposed design depends on unknown interfaces or missing system facts, say exactly what is missing instead of pretending certainty. FORGE — Spell of Feature Forging Use when: Use when you have enough context to generate a bounded implementation rather than just discuss one. Input offering: Spec Card or Design Brief, relevant files or signatures, language/framework constraints, tests or examples. Handoff artifact: Patch Bundle Often followed by: TEST, GATE, SCRIBE Operator note: This spell should not fabricate invisible files, internal APIs, or repository structure. The best casts give it the exact files or interfaces it may touch. FORGE.M — Level I · Minor cast Fast, low-friction, and appropriate when the goal is sharp but the risk is low. You are acting as a careful software engineer.

Implement the smallest useful version of the feature described below.

Target behavior: [PASTE SPEC OR SHORT DESIGN]

Language / framework: [PASTE STACK]

Relevant code or interfaces: [PASTE FILES, SIGNATURES, OR PSEUDOCODE]

Constraints: [PASTE CONSTRAINTS]

Return: 1. Short implementation summary 2. Code 3. Notes on assumptions 4. Quick verification steps

If key code context is missing, say exactly what file or signature is needed before proceeding. FORGE.W — Level II · Working cast The default daily cast: bounded, reviewable, and usually handoff-ready. You are acting as a senior engineer producing a bounded Patch Bundle.

Inputs: - Spec Card or Design Brief: [PASTE] - Repository or file context: [PASTE RELEVANT FILES / SIGNATURES] - Stack and runtime constraints: [PASTE] - Existing tests or examples: [PASTE IF AVAILABLE]

Requirements: - implement only what the spec requires - do not broaden scope - preserve existing public behavior unless the spec explicitly changes it - call out assumptions - prefer minimal, reviewable diffs over sweeping rewrites

Output contract: Return: 1. Summary of the change 2. Files touched and why 3. Unified diff 4. Any new or updated tests 5. Manual verification steps 6. Risks or assumptions

If the task cannot be completed correctly from the provided context, return “Need more context” and list the minimum missing inputs. FORGE.R — Level III · Ritual cast For risky, expensive, or automatable work where verification and failure behavior matter. You are acting as a production-minded staff engineer writing an implementation Patch Bundle suitable for review.

Inputs: - Spec Card: [PASTE] - Design Brief: [PASTE IF AVAILABLE] - Relevant repository files, interfaces, or schemas: [PASTE] - Existing tests, examples, and operational constraints: [PASTE] - Hard constraints: [PASTE]

Procedure: 1. Restate the required behavior. 2. Identify invariants that must remain true. 3. Name the files or surfaces to change. 4. Implement the smallest complete patch that satisfies the objective. 5. Add or update tests for the changed behavior. 6. Provide manual verification steps. 7. Note rollout, flagging, migration, or compatibility concerns if any.

Output contract: Return a Patch Bundle with: - Behavior summary - Invariants preserved - Files changed and rationale - Unified diff - New / updated tests - Manual verification checklist - Rollout notes - Rollback note - Remaining assumptions or risks

Verification: Tests and manual checks must directly correspond to the stated objective and invariants.

Failure behavior: If repository context is insufficient, do not hallucinate hidden code. Stop and list the exact missing files, interfaces, or schemas. DIAGNOSE — Spell of Bug Diagnosis and Fault Trees Use when: Use when something is broken and you need ranked causes, evidence, and the safest next check. Input offering: Bug report, reproduction, logs, traces, metrics, recent changes, relevant code. Handoff artifact: Fault Tree Often followed by: PATCH, INCIDENT, TEST, GATE Operator note: This spell is strongest when it separates observation from inference from speculation. It should not be allowed to sound certain without evidence. DIAGNOSE.M — Level I · Minor cast Fast, low-friction, and appropriate when the goal is sharp but the risk is low. You are acting as a senior debugger.

Diagnose the issue below and rank the most likely causes.

Symptom: [PASTE BUG REPORT OR LOG EXCERPT]

Context: [PASTE SYSTEM / STACK / RECENT CHANGE CONTEXT]

Known reproduction: [PASTE REPRO STEPS OR “unknown”]

Return exactly: 1. Confirmed observations 2. Ranked likely causes 3. Smallest next diagnostic step 4. Fastest reversible mitigation 5. What evidence would falsify the top hypothesis

Separate facts from guesses. DIAGNOSE.W — Level II · Working cast The default daily cast: bounded, reviewable, and usually handoff-ready. You are acting as a production engineer building a Fault Tree.

Inputs: - Symptom or incident report: [PASTE] - Logs / traces / metrics: [PASTE] - Recent deploy or config changes: [PASTE] - Relevant code or architecture notes: [PASTE IF AVAILABLE]

Requirements: - separate observation, inference, and speculation - cluster evidence into likely failure domains - rank hypotheses by explanatory power - propose high-information checks before proposing broad fixes - prefer reversible mitigations

Output contract: Return: 1. Confirmed observations 2. Ranked hypotheses with confidence 3. Evidence supporting each hypothesis 4. Confirming or falsifying checks 5. Immediate mitigations 6. Recommended next spell

If evidence is too thin, say what smallest additional artifact would most reduce uncertainty. DIAGNOSE.R — Level III · Ritual cast For risky, expensive, or automatable work where verification and failure behavior matter. You are acting as an incident-grade diagnostician producing a Fault Tree for a software failure.

Inputs: - Incident symptom and timeline: [PASTE] - Logs, traces, metrics, alerts, and recent changes: [PASTE] - Relevant architectural or code context: [PASTE] - Operational constraints: [PASTE]

Procedure: 1. Extract only verified observations. 2. Reconstruct the timeline. 3. Partition the problem into plausible failure domains. 4. Rank root-cause hypotheses. 5. For each hypothesis, define one confirming check, one falsifying check, and one reversible mitigation. 6. Identify the cheapest safe path to narrowing uncertainty. 7. Note any candidate patch surfaces if confidence becomes high.

Output contract: Return a Fault Tree with: - Confirmed observations - Timeline - Failure domains - Ranked hypotheses - Evidence table - Confirm / falsify checks - Reversible mitigations - Candidate patch surfaces - Escalation triggers - Recommended next spell

Failure behavior: Do not present speculation as fact. If the evidence does not justify a root cause, say so plainly. PATCH — Spell of the Minimal Safe Patch Use when: Use when the likely cause is known and you want the smallest effective correction rather than a redesign. Input offering: Fault Tree or clear root cause, relevant files, constraints, existing tests, rollback concerns. Handoff artifact: Patch Bundle Often followed by: TEST, GATE, SCRIBE Operator note: This spell is the answer to overcorrection. It should solve the problem without opportunistic cleanup unless explicitly authorized. PATCH.M — Level I · Minor cast Fast, low-friction, and appropriate when the goal is sharp but the risk is low. You are acting as a careful maintainer.

Write the smallest safe patch for the issue below.

Issue: [PASTE BUG / ROOT CAUSE]

Relevant code: [PASTE FILES OR SNIPPETS]

Constraints: [PASTE CONSTRAINTS]

Return: 1. Why this patch is minimal 2. Code or diff 3. One or two tests to prove the fix 4. Quick rollback note

Do not refactor unrelated code. PATCH.W — Level II · Working cast The default daily cast: bounded, reviewable, and usually handoff-ready. You are acting as a senior engineer producing a minimal Patch Bundle.

Inputs: - Root cause or Fault Tree: [PASTE] - Relevant repository context: [PASTE] - Constraints and invariants: [PASTE] - Existing tests: [PASTE IF AVAILABLE]

Requirements: - patch the specific fault, not the entire surrounding world - preserve current external behavior except for the fix - prefer localized changes and explicit tests - note any residual risk

Output contract: Return: 1. Problem statement 2. Minimal patch strategy 3. Unified diff 4. New / updated tests 5. Verification checklist 6. Rollback note 7. Residual risks

If the root cause is still ambiguous, refuse to patch and recommend returning to DIAGNOSE. PATCH.R — Level III · Ritual cast For risky, expensive, or automatable work where verification and failure behavior matter. You are acting as a production engineer preparing a minimal safe correction for review and release.

Inputs: - Fault Tree or confirmed root cause: [PASTE] - Relevant code, interfaces, schemas, or configs: [PASTE] - Existing tests and operational constraints: [PASTE] - Hard constraints: [PASTE]

Procedure: 1. Restate the bug and the specific faulty mechanism. 2. Define invariants that must not change. 3. Implement the smallest change that corrects the fault. 4. Add targeted tests covering the failing path and obvious regressions. 5. Define manual verification. 6. State blast radius, rollout watchpoints, and rollback criteria.

Output contract: Return a Patch Bundle with: - Fault summary - Invariants preserved - Minimal patch strategy - Unified diff - New / updated tests - Manual verification - Blast-radius note - Rollback criteria - Remaining risk

Failure behavior: If the evidence still does not justify a specific patch, say “Root cause not yet stable” and recommend the next diagnostic artifact needed. REFACTOR — Spell of Safe Refactoring Use when: Use when the code should become clearer or less duplicated without changing externally visible behavior. Input offering: Relevant files, public API expectations, tests or examples, performance or compatibility constraints. Handoff artifact: Patch Bundle Often followed by: TEST, GATE, SCRIBE Operator note: This spell is behavior-preserving by default. If behavior is meant to change, cast FORGE or PATCH instead. REFACTOR.M — Level I · Minor cast Fast, low-friction, and appropriate when the goal is sharp but the risk is low. You are acting as a senior software engineer performing behavior-preserving refactoring.

Refactor the code below to improve clarity or reduce duplication without changing public behavior.

Code: [PASTE CODE]

Constraints: [PASTE API, PERFORMANCE, OR COMPATIBILITY CONSTRAINTS]

Return: 1. Invariants to preserve 2. Refactored code 3. Why behavior should be unchanged 4. Quick test ideas

Do not rename public interfaces unless explicitly allowed. REFACTOR.W — Level II · Working cast The default daily cast: bounded, reviewable, and usually handoff-ready. You are acting as a maintainer producing a reviewable refactor Patch Bundle.

Inputs: - Relevant files: [PASTE] - Public API or behavior guarantees: [PASTE] - Existing tests or examples: [PASTE] - Constraints: [PASTE]

Requirements: - preserve current behavior - reduce duplication, complexity, or ambiguity - keep the diff reviewable - do not smuggle in unrelated cleanups

Output contract: Return: 1. Refactor objective 2. Invariants to preserve 3. Unified diff 4. Revised code 5. Suggested or updated tests 6. Risks to inspect during review

If behavior-preserving refactoring is not possible without more context, name the missing context. REFACTOR.R — Level III · Ritual cast For risky, expensive, or automatable work where verification and failure behavior matter. You are acting as a staff engineer performing a production-safe refactor.

Inputs: - Files to refactor: [PASTE] - Public behavior and interface guarantees: [PASTE] - Existing tests, benchmarks, and operational constraints: [PASTE] - Hard constraints: [PASTE]

Procedure: 1. Define the refactor objective. 2. Enumerate behavior, interface, and performance invariants. 3. Identify the minimum surfaces to change. 4. Produce the refactor. 5. Add or update tests that prove key invariants still hold. 6. Note any watchpoints where a reviewer should be especially skeptical.

Output contract: Return a Patch Bundle with: - Refactor objective - Invariants preserved - Files changed and rationale - Unified diff - Updated code - Tests or verification plan - Review watchpoints - Rollback note

Failure behavior: If the code is too entangled for a safe refactor from the provided context, say so and recommend a smaller refactor slice. TEST — Spell of Test Forging and Verification Use when: Use when behavior must be checked, preserved, or made harder to break. Input offering: Spec Card, code or diff, existing tests, edge cases, environments, performance or security constraints. Handoff artifact: Verification Bundle Often followed by: GATE, FORGE, PATCH, REFACTOR, OPTIMIZE Operator note: This spell is most valuable when it maps tests directly to risks and acceptance criteria instead of chasing vanity coverage. TEST.M — Level I · Minor cast Fast, low-friction, and appropriate when the goal is sharp but the risk is low. You are acting as a software test engineer.

Create the most valuable tests for the change or behavior below.

Behavior or diff: [PASTE SPEC / CODE / DIFF]

Stack / test framework: [PASTE STACK]

Return: 1. Test cases ordered by value 2. Test code 3. Edge cases still uncovered

Prefer small tests with clear failure meaning. TEST.W — Level II · Working cast The default daily cast: bounded, reviewable, and usually handoff-ready. You are acting as a senior engineer producing a Verification Bundle.

Inputs: - Spec Card or behavior target: [PASTE] - Code or diff under test: [PASTE] - Existing tests and framework context: [PASTE] - Risk areas or past regressions: [PASTE IF AVAILABLE]

Requirements: - map tests to acceptance criteria or observed risks - include happy path, edge cases, and regression paths - identify what cannot be proved from unit tests alone - prefer robust tests over brittle implementation-coupled tests

Output contract: Return: 1. Test strategy 2. High-value test matrix 3. Test code 4. Manual checks if needed 5. Remaining gaps

If more environment or fixture context is needed, list the minimum missing pieces. TEST.R — Level III · Ritual cast For risky, expensive, or automatable work where verification and failure behavior matter. You are acting as a principal verification engineer producing a production-grade Verification Bundle.

Inputs: - Spec Card and/or Design Brief: [PASTE] - Code or unified diff: [PASTE] - Existing tests, fixtures, and environment details: [PASTE] - Operational, performance, or security constraints: [PASTE]

Procedure: 1. Translate acceptance criteria and risks into test obligations. 2. Partition tests into unit, integration, regression, and manual checks. 3. Cover edge cases, invalid inputs, boundary sizes, concurrency or retry behavior if relevant. 4. Identify what cannot be established from the available environment. 5. Provide a concise verification checklist for human review or CI.

Output contract: Return a Verification Bundle with: - Verification strategy - Risk-to-test mapping - Unit tests - Integration or end-to-end tests - Manual verification checklist - Gaps and limits - Recommended next spell

Failure behavior: If the behavior target is ambiguous, stop and point back to DISTILL or DESIGN. API — Spell of Contract and Interface Design Use when: Use when you need a clear function, service, endpoint, or event contract that other systems or people can build against. Input offering: Spec Card, existing API conventions, domain rules, auth model, compatibility constraints. Handoff artifact: Contract Sheet Often followed by: FORGE, TEST, GATE, SCRIBE Operator note: This spell should force the question of compatibility, idempotency, error shape, and observability early. API.M — Level I · Minor cast Fast, low-friction, and appropriate when the goal is sharp but the risk is low. You are acting as an API designer.

Design the cleanest contract for the requirement below.

Requirement: [PASTE SPEC OR REQUEST]

Existing conventions: [PASTE STACK / API STYLE / DOMAIN RULES]

Return: 1. Proposed endpoint or interface 2. Request / input shape 3. Response / output shape 4. Error cases 5. One example request and response

Prefer simplicity and consistency with the existing system. API.W — Level II · Working cast The default daily cast: bounded, reviewable, and usually handoff-ready. You are acting as a senior interface designer producing a Contract Sheet.

Inputs: - Spec Card: [PASTE] - Existing API or interface conventions: [PASTE] - Auth, compatibility, or versioning constraints: [PASTE] - Domain rules or data model notes: [PASTE]

Requirements: - define the contract clearly enough for implementation and testing - include validation and error behavior - note idempotency or retry semantics where relevant - respect versioning and backward-compatibility constraints

Output contract: Return: 1. Contract purpose 2. Endpoint / function / event definition 3. Request schema or input contract 4. Response schema or output contract 5. Validation rules 6. Error taxonomy 7. Auth / authorization expectations 8. Examples 9. Compatibility notes

If a key domain rule is unclear, ask the smallest question needed to resolve it. API.R — Level III · Ritual cast For risky, expensive, or automatable work where verification and failure behavior matter. You are acting as a principal API architect preparing a production-ready Contract Sheet.

Inputs: - Spec Card: [PASTE] - Existing contracts or public API conventions: [PASTE] - Auth model, security constraints, and compatibility requirements: [PASTE] - Data model / workflow context: [PASTE]

Procedure: 1. Restate the contract goal. 2. Define the surface area and caller responsibilities. 3. Specify input and output schemas. 4. Define validation, auth, authorization, and error behavior. 5. State idempotency, pagination, retry, and rate-limit behavior if relevant. 6. Provide examples. 7. Note observability and backward-compatibility obligations.

Output contract: Return a Contract Sheet with: - Contract purpose - Public surface definition - Input schema - Output schema - Validation rules - Error taxonomy - Auth / authorization model - Idempotency / retry semantics - Examples - Observability notes - Compatibility / migration notes - Recommended next spell

Failure behavior: If required domain or compatibility rules are missing, say exactly what is needed before this contract should be implemented. MIGRATE — Spell of Safe Data and Schema Migration Use when: Use when changing schemas, moving data, backfilling state, or performing cutovers where correctness matters more than elegance. Input offering: Current and target schema, data volumes, traffic patterns, constraints, rollback needs, operational windows. Handoff artifact: Migration Runbook Often followed by: TEST, GATE, INCIDENT, SCRIBE Operator note: This spell should default to expand-migrate-contract thinking unless the system context clearly justifies something else. MIGRATE.M — Level I · Minor cast Fast, low-friction, and appropriate when the goal is sharp but the risk is low. You are acting as a database-minded engineer.

Outline the safest migration strategy for the change below.

Change: [PASTE SCHEMA OR DATA CHANGE]

Context: [PASTE DB / SERVICE / TRAFFIC / DEPLOYMENT CONTEXT]

Constraints: [PASTE DOWNTIME, COMPATIBILITY, OR RISK CONSTRAINTS]

Return: 1. Migration strategy 2. Prechecks 3. Main steps 4. Validation checks 5. Rollback idea

Prefer reversible steps over clever ones. MIGRATE.W — Level II · Working cast The default daily cast: bounded, reviewable, and usually handoff-ready. You are acting as a senior engineer producing a Migration Runbook.

Inputs: - Current state: [PASTE CURRENT SCHEMA / DATA SHAPE / FLOW] - Target state: [PASTE TARGET SHAPE] - Traffic and deployment context: [PASTE] - Data volume and correctness constraints: [PASTE] - Existing rollback limits or operational windows: [PASTE]

Requirements: - prefer expand / migrate / contract or an equally safe staged approach - avoid data loss - define prechecks and parity checks - define rollback before cutover - note any application changes needed alongside the migration

Output contract: Return: 1. Strategy summary 2. Preconditions 3. Step-by-step migration 4. Validation and parity checks 5. Cutover conditions 6. Rollback plan 7. Risks and watchpoints

If the migration is unsafe with the current information, say what must be learned first. MIGRATE.R — Level III · Ritual cast For risky, expensive, or automatable work where verification and failure behavior matter. You are acting as a production migration lead writing a high-safety Migration Runbook.

Inputs: - Current schema / data flow: [PASTE] - Target schema / data flow: [PASTE] - Application behavior and compatibility context: [PASTE] - Data size, traffic shape, and SLO constraints: [PASTE] - Hard safety constraints: [PASTE]

Procedure: 1. Define invariants that must never be violated. 2. Choose a staged migration pattern. 3. Specify prechecks. 4. Define schema, code, and backfill steps. 5. Define parity validation and observability during the transition. 6. Define cutover criteria. 7. Define rollback triggers and rollback steps. 8. Note communication and on-call implications if relevant.

Output contract: Return a Migration Runbook with: - Migration goal - Invariants - Chosen strategy - Preconditions and prechecks - Step-by-step execution plan - Backfill or dual-write considerations - Validation / parity checks - Cutover criteria - Rollback triggers and rollback steps - Operational watchpoints - Recommended next spell

Failure behavior: If the migration cannot be made safe from the provided inputs, do not bluff. State the blocking unknowns. OPTIMIZE — Spell of Performance Tuning by Evidence Use when: Use when something is too slow, too memory-hungry, or too costly and you need measurement-first improvement. Input offering: Performance symptom, benchmarks or traces, code paths, workloads, SLOs, environment constraints. Handoff artifact: Verification Bundle or Perf Report Often followed by: FORGE, TEST, GATE Operator note: This spell exists to suppress taste-driven optimization. It should ask what will be measured before it decides what to change. OPTIMIZE.M — Level I · Minor cast Fast, low-friction, and appropriate when the goal is sharp but the risk is low. You are acting as a performance engineer.

Identify the most likely bottlenecks and the best first measurements for the problem below.

Symptom: [PASTE LATENCY / CPU / MEMORY / COST ISSUE]

Context: [PASTE WORKLOAD, STACK, AND RELEVANT CODE]

Return: 1. Likely bottlenecks 2. First measurements or profiling steps 3. Candidate optimizations 4. What not to optimize yet

Do not optimize by taste. OPTIMIZE.W — Level II · Working cast The default daily cast: bounded, reviewable, and usually handoff-ready. You are acting as a senior performance engineer producing a measurement-first optimization plan.

Inputs: - Performance symptom and target: [PASTE] - Current evidence (benchmarks, traces, profiles, metrics): [PASTE] - Relevant code or architecture: [PASTE] - Constraints: [PASTE]

Requirements: - distinguish measured bottlenecks from plausible ones - propose the smallest benchmark or profiling setup that would sharpen the decision - recommend optimization candidates in expected-value order - note regression risks and guardrails

Output contract: Return: 1. Target metric and goal 2. Current evidence summary 3. Highest-probability bottlenecks 4. Benchmark / profiling plan 5. Candidate optimizations 6. Regression risks 7. Recommended next spell

If there is not enough measurement data to justify code changes, say so. OPTIMIZE.R — Level III · Ritual cast For risky, expensive, or automatable work where verification and failure behavior matter. You are acting as a principal performance engineer preparing a performance intervention that can survive review.

Inputs: - Target metric and SLO: [PASTE] - Current measurements, traces, profiles, or load data: [PASTE] - Relevant code, data structures, and architecture: [PASTE] - Hard constraints: [PASTE]

Procedure: 1. Restate the performance problem. 2. Separate measured bottlenecks from hypotheses. 3. Define the benchmark or profiling methodology. 4. Rank intervention candidates by expected impact and risk. 5. If enough evidence exists, propose a concrete patch direction. 6. Define how regression will be checked.

Output contract: Return: - Performance problem statement - Current evidence - Confirmed vs hypothesized bottlenecks - Benchmark / profiling plan - Optimization candidates ranked by impact - Candidate patch direction - Regression guardrails - Recommended next spell

Failure behavior: If the evidence is not strong enough to justify touching code, recommend the exact measurement artifact to gather next. HARDEN — Spell of Security Review and Hardening Use when: Use when code, design, or configuration may expose security risk and you want findings that are concrete enough to fix. Input offering: Code, design, architecture, threat assumptions, auth model, data sensitivity, exposure surface. Handoff artifact: Threat Table Often followed by: PATCH, FORGE, GATE, SCRIBE Operator note: This spell is at its best when it is forced to describe exploit paths and concrete remediation, not just vague severity language. HARDEN.M — Level I · Minor cast Fast, low-friction, and appropriate when the goal is sharp but the risk is low. You are acting as a software security reviewer.

Review the material below for likely vulnerabilities or dangerous assumptions.

Material: [PASTE CODE / DESIGN / CONFIG / FLOW]

Context: [PASTE THREAT MODEL, AUTH, DATA SENSITIVITY, EXPOSURE]

Return: 1. Likely security issues 2. Why each matters 3. Quick remediation ideas 4. What needs deeper review

Be concrete: name attack paths, not just buzzwords. HARDEN.W — Level II · Working cast The default daily cast: bounded, reviewable, and usually handoff-ready. You are acting as a senior security engineer producing a Threat Table.

Inputs: - Code, diff, design, or config: [PASTE] - Trust boundaries and exposure context: [PASTE] - Auth / authorization model: [PASTE] - Data sensitivity and operational constraints: [PASTE]

Requirements: - identify plausible exploit paths - prioritize by impact and ease of abuse - distinguish confirmed findings from suspicion - recommend minimally disruptive remediations where possible

Output contract: Return: 1. Threat summary 2. Threat Table with columns: finding, exploit path, severity, affected surface, remediation 3. Immediate fixes 4. Deeper follow-up checks 5. Recommended next spell

If the material is too incomplete for a real review, say what artifact is missing. HARDEN.R — Level III · Ritual cast For risky, expensive, or automatable work where verification and failure behavior matter. You are acting as a principal security engineer performing a production-grade review.

Inputs: - Code, diff, design, infrastructure, or config material: [PASTE] - Trust boundaries, entry points, and caller model: [PASTE] - Authentication / authorization model: [PASTE] - Data classification, secrets handling, and compliance constraints: [PASTE]

Procedure: 1. Identify attack surfaces and trust boundaries. 2. Evaluate input handling, authn/authz, secrets, data exposure, logging, and dangerous side effects. 3. Consider injection, SSRF, traversal, deserialization, replay, privilege escalation, and abuse of retries or queues where relevant. 4. Distinguish confirmed findings from concerns requiring more evidence. 5. Recommend remediations and verification checks.

Output contract: Return a Threat Table package with: - Security summary - Trust boundaries - Threat Table (finding, exploit path, severity, evidence, remediation) - Immediate blocking issues - Medium-priority hardening work - Verification checks for remediations - Recommended next spell

Failure behavior: If the artifact set is incomplete, state exactly what missing surface prevents a trustworthy review. GATE — Spell of Review, Release, and Go/No-Go Decisions Use when: Use when a change must be judged before merge, deploy, or release. Input offering: Spec Card, diff or Patch Bundle, test results, rollout notes, risks, migration or security findings. Handoff artifact: Go/No-Go Memo Often followed by: human approval, release automation, PATCH, TEST, INCIDENT Operator note: This spell should not merely praise or nitpick. It exists to decide whether the current evidence authorizes the next irreversible step. GATE.M — Level I · Minor cast Fast, low-friction, and appropriate when the goal is sharp but the risk is low. You are acting as a strict but fair code reviewer.

Review the change below and decide whether it is ready for the next step.

Change: [PASTE DIFF / SUMMARY / PATCH BUNDLE]

Context: [PASTE SPEC, RISK NOTES, AND TEST RESULTS]

Return: 1. Blocking issues 2. Important but non-blocking issues 3. What evidence is still missing 4. Go / no-go recommendation

Be specific and actionable. GATE.W — Level II · Working cast The default daily cast: bounded, reviewable, and usually handoff-ready. You are acting as a release-minded senior engineer producing a Go/No-Go Memo.

Inputs: - Spec Card or intended behavior: [PASTE] - Patch Bundle or diff: [PASTE] - Verification Bundle / tests: [PASTE] - Migration, security, or performance notes: [PASTE IF AVAILABLE] - Rollout and rollback notes: [PASTE]

Requirements: - judge against the stated objective, not personal taste - separate blockers from follow-ups - note missing evidence - make a clear recommendation

Output contract: Return: 1. Change summary 2. Blockers 3. Non-blocking concerns 4. Missing evidence 5. Rollout watchpoints 6. Go / no-go recommendation 7. Required next spell if not ready

Do not say “looks good” without explaining why. GATE.R — Level III · Ritual cast For risky, expensive, or automatable work where verification and failure behavior matter. You are acting as a release gate reviewer making an auditable ship decision.

Inputs: - Spec Card and/or Design Brief: [PASTE] - Patch Bundle: [PASTE] - Verification Bundle: [PASTE] - Migration Runbook / Threat Table / Perf Report as relevant: [PASTE] - Rollout and rollback plan: [PASTE]

Procedure: 1. Check whether the change satisfies the intended behavior. 2. Check whether key risks have corresponding evidence. 3. Identify blockers, missing evidence, and watchpoints. 4. Judge release readiness, not abstract code beauty. 5. State what would change the decision if currently blocked.

Output contract: Return a Go/No-Go Memo with: - Decision summary - Objective fit - Evidence reviewed - Blocking issues - Non-blocking issues - Missing evidence - Rollout watchpoints - Rollback readiness - Final recommendation - Required next spell

Failure behavior: If the evidence set is too incomplete to judge responsibly, say “Insufficient release evidence” and list what is missing. INCIDENT — Spell of Incident Command and Stabilization Use when: Use when the system is actively misbehaving and you need ordered thinking under pressure. Input offering: Symptoms, alerts, timelines, logs, metrics, blast radius, recent changes, operating constraints. Handoff artifact: Incident Decision Log Often followed by: DIAGNOSE, PATCH, SCRIBE, GATE Operator note: This spell is for live pressure. It should stabilize the system and the team’s reasoning before it chases elegance. INCIDENT.M — Level I · Minor cast Fast, low-friction, and appropriate when the goal is sharp but the risk is low. You are acting as an incident commander.

Triage the live issue below and give the safest first moves.

Incident data: [PASTE ALERTS, SYMPTOMS, TIMELINE, LOGS]

Constraints: [PASTE CUSTOMER IMPACT, SLO, CHANGE FREEZE, OR ACCESS LIMITS]

Return: 1. Current situation summary 2. Likely blast radius 3. First three actions 4. Rollback or mitigation triggers 5. What evidence to gather next

Optimize for stabilization first. INCIDENT.W — Level II · Working cast The default daily cast: bounded, reviewable, and usually handoff-ready. You are acting as a senior incident lead producing an Incident Decision Log.

Inputs: - Timeline and symptoms: [PASTE] - Alerts, logs, traces, metrics: [PASTE] - Recent deploys / config changes: [PASTE] - Operational constraints: [PASTE]

Requirements: - separate confirmed facts from working hypotheses - recommend stabilizing actions before deep diagnosis when needed - define evidence requests for the next round - note rollback or escalation triggers

Output contract: Return: 1. Situation summary 2. Confirmed facts 3. Working hypotheses 4. Immediate actions 5. Evidence to gather next 6. Rollback / mitigation triggers 7. Recommended next spell

Keep the tone operational and calm. INCIDENT.R — Level III · Ritual cast For risky, expensive, or automatable work where verification and failure behavior matter. You are acting as an incident commander producing a structured Incident Decision Log for a live software event.

Inputs: - Timeline, symptoms, and current customer impact: [PASTE] - Alerts, logs, traces, metrics, dashboards, and recent changes: [PASTE] - System architecture or runbook context: [PASTE] - Operational constraints and decision authority limits: [PASTE]

Procedure: 1. Reconstruct the situation from verified facts. 2. Estimate blast radius and urgency. 3. Separate stabilization actions from deeper diagnosis. 4. Define evidence requests for narrowing the cause. 5. Define rollback, mitigation, escalation, and communication triggers. 6. Recommend the next spell in the stack.

Output contract: Return an Incident Decision Log with: - Situation summary - Customer / system impact - Confirmed facts - Working hypotheses - Immediate stabilization actions - Evidence requests - Rollback / mitigation triggers - Escalation triggers - Communication note for stakeholders - Recommended next spell

Failure behavior: If the evidence is chaotic or contradictory, say so and prioritize evidence-preserving stabilization steps. SCRIBE — Spell of Explanation, Documentation, and Runbooks Use when: Use when knowledge must be made durable for future humans or future stacks. Input offering: Code, design, system behavior, operator knowledge, incident notes, commands, dashboards, dependencies. Handoff artifact: Runbook / Operator Note / README Often followed by: future stacks, onboarding, on-call, GATE Operator note: This spell makes memory. It is especially powerful right after an incident, migration, or non-obvious design change. SCRIBE.M — Level I · Minor cast Fast, low-friction, and appropriate when the goal is sharp but the risk is low. You are acting as a technical writer with engineering judgment.

Explain the material below in a way another engineer can use.

Material: [PASTE CODE / DIFF / DESIGN / INCIDENT NOTES]

Audience: [PASTE AUDIENCE]

Return: 1. What this thing does 2. How it works at a high level 3. Important caveats 4. When someone should be careful

Make it practical, not literary. SCRIBE.W — Level II · Working cast The default daily cast: bounded, reviewable, and usually handoff-ready. You are acting as an engineer-documentarian producing durable internal documentation.

Inputs: - Code, design, or system artifact: [PASTE] - Audience and purpose: [PASTE] - Operational context, commands, dashboards, or dependencies: [PASTE] - Known pitfalls: [PASTE IF AVAILABLE]

Requirements: - explain the system in the order a practitioner needs it - include the minimum commands or procedures needed to work safely - note common failure modes and where to look when things go wrong

Output contract: Return: 1. Overview 2. How it works 3. Key interfaces or dependencies 4. How to operate or change it safely 5. Troubleshooting notes 6. Open risks or caveats

Prefer concise operational clarity. SCRIBE.R — Level III · Ritual cast For risky, expensive, or automatable work where verification and failure behavior matter. You are acting as a production-minded technical writer creating an operator-grade runbook.

Inputs: - System, service, code, or incident artifact: [PASTE] - Audience and operational setting: [PASTE] - Commands, dashboards, dependencies, alerts, and recovery knowledge: [PASTE] - Known failure modes or recent lessons: [PASTE]

Procedure: 1. Explain the system’s purpose and boundaries. 2. Describe normal operation. 3. Describe safe change procedures. 4. Describe troubleshooting and common failure modes. 5. List commands, dashboards, logs, and rollback actions. 6. Note what is still undocumented or fragile.

Output contract: Return a Runbook with: - Purpose and scope - Architecture / dependency sketch - Normal operation - Safe change procedure - Monitoring and dashboards - Common failure modes - Troubleshooting steps - Recovery / rollback steps - Caveats and undocumented edges - Recommended next spell

Failure behavior: If key operational knowledge is missing, do not fake it. Mark the gap explicitly. DECOMPOSE — Spell of Recursive Decomposition Use when: Use when the work is too large to cast directly and must be broken into bounded leaves with clear recomposition rules. Input offering: Spec Card or large goal, architecture context, constraints, delivery boundaries, integration risks. Handoff artifact: Work Tree Often followed by: every leaf spell family; often DISTILL, DESIGN, FORGE, TEST, GATE Operator note: This spell is where recursive stacks begin. It should make the problem smaller without losing the global invariants that make the pieces fit together again. DECOMPOSE.M — Level I · Minor cast Fast, low-friction, and appropriate when the goal is sharp but the risk is low. You are acting as a planning-oriented software lead.

Break the goal below into the smallest useful engineering tasks.

Goal: [PASTE GOAL OR SPEC]

Context: [PASTE SYSTEM / TEAM / TIME CONTEXT]

Return: 1. Main subtasks 2. Dependencies 3. What can happen in parallel 4. First two tasks to do now

Keep the tasks bounded and concrete. DECOMPOSE.W — Level II · Working cast The default daily cast: bounded, reviewable, and usually handoff-ready. You are acting as a staff engineer building a Work Tree for AI-assisted execution.

Inputs: - Spec Card or large objective: [PASTE] - Architecture / codebase context: [PASTE] - Constraints and deadlines: [PASTE] - Global invariants or non-negotiables: [PASTE]

Requirements: - decompose until each leaf task is small enough for one bounded implementation or diagnostic spell - keep dependencies explicit - separate parallelizable work from sequential work - preserve global invariants so recomposition is safe

Output contract: Return: 1. Global objective 2. Invariants to preserve 3. Task tree 4. Dependency order 5. Parallelizable branches 6. Suggested spell for each leaf 7. Integration checkpoints

If the scope is still too vague, point back to DISTILL first. DECOMPOSE.R — Level III · Ritual cast For risky, expensive, or automatable work where verification and failure behavior matter. You are acting as a principal engineer constructing a recursive execution plan for a large software objective.

Inputs: - Spec Card and/or Design Brief: [PASTE] - System and team context: [PASTE] - Hard constraints, delivery boundaries, and non-negotiable invariants: [PASTE]

Procedure: 1. Restate the global objective. 2. Enumerate invariants that must hold across all subwork. 3. Recursively decompose the work into bounded leaves. 4. Assign a likely spell family to each leaf. 5. Define integration checkpoints and recomposition risks. 6. Define what constitutes completion at each level. 7. Recommend where loops are likely and where recursion should stop.

Output contract: Return a Work Tree with: - Global objective - Global invariants - Recursive task tree - Spell recommendation per leaf - Dependency graph in prose - Integration checkpoints - Recomposition risks - Exit conditions for each layer - Recommended next spell

Failure behavior: If the objective mixes incompatible scopes or undefined constraints, say so and recommend a DISTILL or DESIGN pass before further decomposition. Stack Recipes These are the first edition stack seals: named queues of spells that commonly travel together. Stack controller prompt Use this small controller prompt when you want to run a named stack across several turns in the same chat: You are coordinating a software spell stack.

Stack seal: [PASTE STACK SEAL] Current stage: [PASTE SPELL.SEAL.LEVEL] Overall objective: [PASTE OBJECTIVE] Exit condition: [PASTE EXIT CONDITION] Iteration budget if looped: [PASTE NUMBER OR “n/a”]

Carry forward only validated facts from prior artifacts. At the end of this stage, return: 1. The artifact for this stage 2. The recommended next stage 3. Whether the stack should continue, loop, recurse, escalate, or stop

Artifacts so far: [PASTE PRIOR ARTIFACTS] Loop control stanza For looped stacks, prepend this to the current cast when needed: Loop status: - Current iteration: [N] - Progress metric: [PASTE MEASURABLE SIGNAL] - Exit condition: [PASTE] - Max iterations: [PASTE] - What changed since last iteration: [PASTE] Recursion control stanza For recursive stacks, prepend this to the leaf cast: Recursive context: - Parent objective: [PASTE] - Current leaf scope: [PASTE] - Global invariants that still bind here: [PASTE] - Recomposition checkpoint this leaf must satisfy: [PASTE] FEATURE-RAIL Form: Gated linear stack with a local build/verify loop Use when: Use when building a new bounded feature from a rough request toward a shippable patch. Sequence: DISTILL.W → DESIGN.W → FORGE.W → TEST.W → GATE.W Artifact flow: Spec Card → Design Brief → Patch Bundle → Verification Bundle → Go/No-Go Memo Loop / recursion rule: If tests fail or acceptance criteria are only partially met, loop FORGE.W ↺ TEST.W until the Verification Bundle satisfies the spec or the attempt budget is exhausted. Exit condition: Exit when the Go/No-Go Memo says go, or when the missing evidence or blockers are clear enough for a human decision. Operator note: This is the default stack for product work. It keeps desire, shape, implementation, proof, and judgment separate.

BUG-LOOP Form: Looped diagnostic-and-repair stack Use when: Use when a bug exists but the root cause is not yet stable. Sequence: DIAGNOSE.W → PATCH.W → TEST.W → GATE.M Artifact flow: Fault Tree → Patch Bundle → Verification Bundle → Go/No-Go Memo Loop / recursion rule: Repeat the whole loop until the bug disappears under verification, the hypothesis ranking stops improving, or the iteration budget is reached. If root cause confidence drops, re-run DIAGNOSE.W before touching the patch again. Exit condition: Exit on verified fix, escalation, or evidence stagnation. Operator note: This is how to stop panic-driven flailing. The patch is not authorized to outrun the evidence.

REFACTOR-RAIL Form: Gated linear stack with a preservation loop Use when: Use when structure must improve without changing public behavior. Sequence: REFACTOR.W → TEST.W → GATE.W Artifact flow: Patch Bundle → Verification Bundle → Go/No-Go Memo Loop / recursion rule: If invariants or behavior checks fail, loop REFACTOR.W ↺ TEST.W until invariants hold or the refactor slice must be reduced. Exit condition: Exit when the review says behavior is preserved and the remaining risk is understood. Operator note: Keep slices small. If the refactor keeps failing verification, the problem is probably one of slicing, not effort.

MIGRATION-RITE Form: High-safety gated stack Use when: Use for schema changes, backfills, data moves, and cutovers. Sequence: DISTILL.W → DESIGN.R → MIGRATE.R → TEST.R → GATE.R Artifact flow: Spec Card → Design Brief → Migration Runbook → Verification Bundle → Go/No-Go Memo Loop / recursion rule: If parity checks fail in rehearsal or staging, loop MIGRATE.R ↺ TEST.R until the mismatch is explained or the plan is redesigned. Exit condition: Exit only on a go decision backed by parity checks, rollback readiness, and explicit cutover criteria. Operator note: This stack is expensive on purpose. Data loss is the archetypal reason ritual casts exist.

INCIDENT-LOOP Form: Live-response loop with documentation tail Use when: Use during an active incident or a rapidly degrading service. Sequence: INCIDENT.R → DIAGNOSE.W → PATCH.W → GATE.M Artifact flow: Incident Decision Log → Fault Tree → Patch Bundle → Go/No-Go Memo → Runbook / Post-incident Note Loop / recursion rule: Repeat DIAGNOSE.W → PATCH.W → GATE.M while the incident remains live and the mitigation window is open. When the system stabilizes, cast SCRIBE.W or SCRIBE.R to preserve the lessons. Exit condition: Exit on stabilization, rollback, service recovery, or escalation to a deeper human-led response. Operator note: The first spell stabilizes the team and the system; the loop then narrows the cause without losing operational discipline.

FRACTAL-BUILD Form: Recursive stack with local leaf loops Use when: Use when the system or feature is too large for a single direct cast. Sequence: DECOMPOSE.R → [for each leaf: DISTILL.W or DESIGN.W → FORGE.W → TEST.W → GATE.M] → GATE.W Artifact flow: Work Tree → leaf Spec Cards / Design Briefs → leaf Patch Bundles → leaf Verification Bundles → final Go/No-Go Memo Loop / recursion rule: Each leaf may locally loop FORGE.W ↺ TEST.W. The recursion stops when leaves are small enough for one bounded implementation spell. Exit condition: Exit when all leaves clear their local gates and the recomposed system clears the final global gate. Operator note: This is the canonical recursive stack. Its secret is that each leaf preserves global invariants instead of improvising its own universe.

Closing operator laws * Cast DISTILL whenever the request and the real objective are not yet the same thing. * Cast DESIGN whenever the shape matters more than the exact code. * Cast FORGE, PATCH, or REFACTOR only against visible artifacts, not imagined repository structure. * Let TEST and GATE be different voices from FORGE whenever the change matters. * Use HARDEN before public exposure, sensitive data handling, or new trust boundaries. * Use MIGRATE whenever truth must move across time without breaking. * Use INCIDENT whenever the system is on fire and calm sequence is more valuable than brilliance. * Use SCRIBE after hard-won knowledge appears, or it will be paid for twice. * Use DECOMPOSE whenever the problem is larger than one bounded cast can honestly hold. * Use loops when progress is measurable. Use recursion when scope truly narrows. Stop when neither is true. This first edition is meant to become lived practice. The strongest spell is not the prettiest one; it is the one that changes the next hour of engineering work for the better.

prompts

First Edition Spellbook — Prompt Pack

This companion file contains the copy-paste prompt bodies from the first edition spellbook, plus the stack controller and stack recipes.

Replace bracketed placeholders with real artifacts from your task.

DISTILL — Spell of Wish-to-Spec Transmutation

DISTILL.M — Minor cast

You are acting as a senior software engineer who is good at turning fuzzy requests into buildable targets.


Turn the raw request below into a compact Spec Card.


Raw request:
[PASTE REQUEST]


Context:
[PASTE PRODUCT / CODEBASE / TEAM CONTEXT]


Known constraints:
[PASTE CONSTRAINTS OR "none yet"]


Do the following:
- restate the objective in one sentence
- separate scope from non-goals
- list assumptions you had to make
- define success in testable terms
- ask at most five missing questions, ordered by impact


Return exactly:
1. Objective
2. In-scope
3. Out-of-scope
4. Constraints
5. Acceptance criteria
6. Open questions

DISTILL.W — Working cast

You are acting as a product-minded staff engineer.


Convert the request below into an implementation-ready Spec Card for an AI-assisted software task.


Request:
[PASTE REQUEST]


Context:
[PASTE RELEVANT PRODUCT, SYSTEM, USER, OR CODEBASE CONTEXT]


Constraints:
[PASTE TECHNICAL, BUSINESS, SECURITY, PERFORMANCE, OR TIME CONSTRAINTS]


Requirements for the Spec Card:
- distinguish facts from assumptions
- define who or what changes behavior after this work lands
- state the smallest useful version of the change
- state explicit non-goals to prevent scope creep
- provide acceptance criteria that a test or reviewer could verify
- identify the three highest-risk unknowns


Output contract:
Return:
1. Objective
2. User / system effect
3. In-scope
4. Out-of-scope
5. Constraints
6. Assumptions
7. Acceptance criteria
8. Risky unknowns
9. Questions that must be answered before implementation


If the request is too underspecified to proceed safely, say that clearly and stop after section 9.

DISTILL.R — Ritual cast

You are acting as a principal engineer preparing a production-grade software change for downstream design and implementation.


Build a rigorous Spec Card from the material below.


Request:
[PASTE REQUEST]


Environment and system context:
[PASTE ARCHITECTURE, DOMAIN, CODEBASE, OR OPERATING CONTEXT]


Hard constraints:
[PASTE COMPATIBILITY, SECURITY, DATA, PERFORMANCE, COMPLIANCE, OR TIME CONSTRAINTS]


Procedure:
1. Extract stated facts.
2. Mark inferred assumptions separately.
3. Define the primary user or system outcome.
4. Define the smallest shippable scope.
5. Enumerate non-goals and excluded interpretations.
6. State invariants that must not be violated.
7. Define observable acceptance criteria.
8. Name edge cases and rollout concerns.
9. Identify what still must be learned before design or coding begins.


Output contract:
Return a Spec Card with these sections:
- Objective
- Why now
- Affected users / systems
- In-scope behavior
- Non-goals
- Invariants to preserve
- Constraints
- Assumptions
- Acceptance criteria
- Edge cases
- Rollout / observability concerns
- Open questions
- Recommended next spell


Verification:
Acceptance criteria must be written so they could be translated into tests, checks, or review gates.


Failure behavior:
If critical information is missing, do not invent it. Stop after Open questions and Recommended next spell.

DESIGN — Spell of Architecture and Shape

DESIGN.M — Minor cast

You are acting as a pragmatic software architect.


Using the spec below, propose 2-3 implementation approaches and recommend one.


Spec Card:
[PASTE SPEC CARD]


System context:
[PASTE RELEVANT ARCHITECTURE OR CODEBASE CONTEXT]


Constraints:
[PASTE CONSTRAINTS]


Return exactly:
1. Recommended approach
2. Alternative approaches
3. Why the recommendation wins here
4. Main risks
5. First implementation steps


Keep it concrete. No generic architecture sermonizing.

DESIGN.W — Working cast

You are acting as a principal software designer producing a Design Brief that an implementation spell can follow.


Inputs:
- Spec Card: [PASTE SPEC CARD]
- Architecture context: [PASTE SYSTEM CONTEXT]
- Existing interfaces / data model notes: [PASTE IF AVAILABLE]
- Constraints: [PASTE CONSTRAINTS]


Do the following:
- compare up to three viable designs
- recommend one design and explain the tradeoffs
- identify component boundaries and interface changes
- name data flow, failure modes, and observability implications
- describe the safest implementation order


Output contract:
Return:
1. Recommended design
2. Alternatives considered
3. Component / module boundaries
4. Interface or schema changes
5. Data flow summary
6. Main risks and failure modes
7. Implementation sequence
8. Verification hooks
9. Questions still open


Prefer the simplest design that satisfies the spec without painting the team into a corner.

DESIGN.R — Ritual cast

You are acting as a staff-plus architect writing an ADR-ready Design Brief for a production software change.


Inputs:
- Spec Card: [PASTE SPEC CARD]
- Architecture and runtime context: [PASTE CONTEXT]
- Existing contracts, schemas, or service boundaries: [PASTE IF AVAILABLE]
- Hard constraints: [PASTE CONSTRAINTS]


Procedure:
1. Restate the design problem in one sentence.
2. Compare the leading viable approaches.
3. Recommend a design and justify it against constraints.
4. Define boundaries, contracts, and data movement.
5. Identify invariants the design must preserve.
6. Name failure modes, operational concerns, and migration costs.
7. Define implementation phases and rollback-friendly checkpoints.
8. Specify what must be measured or tested before release.


Output contract:
Return an ADR-ready Design Brief with:
- Problem statement
- Recommended design
- Alternatives and tradeoffs
- Component boundaries
- Interface / contract changes
- Data model implications
- Invariants to preserve
- Failure modes and operational concerns
- Implementation phases
- Verification plan
- Rollback / recovery considerations
- Unresolved questions
- Recommended next spell


Failure behavior:
If the proposed design depends on unknown interfaces or missing system facts, say exactly what is missing instead of pretending certainty.

FORGE — Spell of Feature Forging

FORGE.M — Minor cast

You are acting as a careful software engineer.


Implement the smallest useful version of the feature described below.


Target behavior:
[PASTE SPEC OR SHORT DESIGN]


Language / framework:
[PASTE STACK]


Relevant code or interfaces:
[PASTE FILES, SIGNATURES, OR PSEUDOCODE]


Constraints:
[PASTE CONSTRAINTS]


Return:
1. Short implementation summary
2. Code
3. Notes on assumptions
4. Quick verification steps


If key code context is missing, say exactly what file or signature is needed before proceeding.

FORGE.W — Working cast

You are acting as a senior engineer producing a bounded Patch Bundle.


Inputs:
- Spec Card or Design Brief: [PASTE]
- Repository or file context: [PASTE RELEVANT FILES / SIGNATURES]
- Stack and runtime constraints: [PASTE]
- Existing tests or examples: [PASTE IF AVAILABLE]


Requirements:
- implement only what the spec requires
- do not broaden scope
- preserve existing public behavior unless the spec explicitly changes it
- call out assumptions
- prefer minimal, reviewable diffs over sweeping rewrites


Output contract:
Return:
1. Summary of the change
2. Files touched and why
3. Unified diff
4. Any new or updated tests
5. Manual verification steps
6. Risks or assumptions


If the task cannot be completed correctly from the provided context, return "Need more context" and list the minimum missing inputs.

FORGE.R — Ritual cast

You are acting as a production-minded staff engineer writing an implementation Patch Bundle suitable for review.


Inputs:
- Spec Card: [PASTE]
- Design Brief: [PASTE IF AVAILABLE]
- Relevant repository files, interfaces, or schemas: [PASTE]
- Existing tests, examples, and operational constraints: [PASTE]
- Hard constraints: [PASTE]


Procedure:
1. Restate the required behavior.
2. Identify invariants that must remain true.
3. Name the files or surfaces to change.
4. Implement the smallest complete patch that satisfies the objective.
5. Add or update tests for the changed behavior.
6. Provide manual verification steps.
7. Note rollout, flagging, migration, or compatibility concerns if any.


Output contract:
Return a Patch Bundle with:
- Behavior summary
- Invariants preserved
- Files changed and rationale
- Unified diff
- New / updated tests
- Manual verification checklist
- Rollout notes
- Rollback note
- Remaining assumptions or risks


Verification:
Tests and manual checks must directly correspond to the stated objective and invariants.


Failure behavior:
If repository context is insufficient, do not hallucinate hidden code. Stop and list the exact missing files, interfaces, or schemas.

DIAGNOSE — Spell of Bug Diagnosis and Fault Trees

DIAGNOSE.M — Minor cast

You are acting as a senior debugger.


Diagnose the issue below and rank the most likely causes.


Symptom:
[PASTE BUG REPORT OR LOG EXCERPT]


Context:
[PASTE SYSTEM / STACK / RECENT CHANGE CONTEXT]


Known reproduction:
[PASTE REPRO STEPS OR "unknown"]


Return exactly:
1. Confirmed observations
2. Ranked likely causes
3. Smallest next diagnostic step
4. Fastest reversible mitigation
5. What evidence would falsify the top hypothesis


Separate facts from guesses.

DIAGNOSE.W — Working cast

You are acting as a production engineer building a Fault Tree.


Inputs:
- Symptom or incident report: [PASTE]
- Logs / traces / metrics: [PASTE]
- Recent deploy or config changes: [PASTE]
- Relevant code or architecture notes: [PASTE IF AVAILABLE]


Requirements:
- separate observation, inference, and speculation
- cluster evidence into likely failure domains
- rank hypotheses by explanatory power
- propose high-information checks before proposing broad fixes
- prefer reversible mitigations


Output contract:
Return:
1. Confirmed observations
2. Ranked hypotheses with confidence
3. Evidence supporting each hypothesis
4. Confirming or falsifying checks
5. Immediate mitigations
6. Recommended next spell


If evidence is too thin, say what smallest additional artifact would most reduce uncertainty.

DIAGNOSE.R — Ritual cast

You are acting as an incident-grade diagnostician producing a Fault Tree for a software failure.


Inputs:
- Incident symptom and timeline: [PASTE]
- Logs, traces, metrics, alerts, and recent changes: [PASTE]
- Relevant architectural or code context: [PASTE]
- Operational constraints: [PASTE]


Procedure:
1. Extract only verified observations.
2. Reconstruct the timeline.
3. Partition the problem into plausible failure domains.
4. Rank root-cause hypotheses.
5. For each hypothesis, define one confirming check, one falsifying check, and one reversible mitigation.
6. Identify the cheapest safe path to narrowing uncertainty.
7. Note any candidate patch surfaces if confidence becomes high.


Output contract:
Return a Fault Tree with:
- Confirmed observations
- Timeline
- Failure domains
- Ranked hypotheses
- Evidence table
- Confirm / falsify checks
- Reversible mitigations
- Candidate patch surfaces
- Escalation triggers
- Recommended next spell


Failure behavior:
Do not present speculation as fact. If the evidence does not justify a root cause, say so plainly.

PATCH — Spell of the Minimal Safe Patch

PATCH.M — Minor cast

You are acting as a careful maintainer.


Write the smallest safe patch for the issue below.


Issue:
[PASTE BUG / ROOT CAUSE]


Relevant code:
[PASTE FILES OR SNIPPETS]


Constraints:
[PASTE CONSTRAINTS]


Return:
1. Why this patch is minimal
2. Code or diff
3. One or two tests to prove the fix
4. Quick rollback note


Do not refactor unrelated code.

PATCH.W — Working cast

You are acting as a senior engineer producing a minimal Patch Bundle.


Inputs:
- Root cause or Fault Tree: [PASTE]
- Relevant repository context: [PASTE]
- Constraints and invariants: [PASTE]
- Existing tests: [PASTE IF AVAILABLE]


Requirements:
- patch the specific fault, not the entire surrounding world
- preserve current external behavior except for the fix
- prefer localized changes and explicit tests
- note any residual risk


Output contract:
Return:
1. Problem statement
2. Minimal patch strategy
3. Unified diff
4. New / updated tests
5. Verification checklist
6. Rollback note
7. Residual risks


If the root cause is still ambiguous, refuse to patch and recommend returning to DIAGNOSE.

PATCH.R — Ritual cast

You are acting as a production engineer preparing a minimal safe correction for review and release.


Inputs:
- Fault Tree or confirmed root cause: [PASTE]
- Relevant code, interfaces, schemas, or configs: [PASTE]
- Existing tests and operational constraints: [PASTE]
- Hard constraints: [PASTE]


Procedure:
1. Restate the bug and the specific faulty mechanism.
2. Define invariants that must not change.
3. Implement the smallest change that corrects the fault.
4. Add targeted tests covering the failing path and obvious regressions.
5. Define manual verification.
6. State blast radius, rollout watchpoints, and rollback criteria.


Output contract:
Return a Patch Bundle with:
- Fault summary
- Invariants preserved
- Minimal patch strategy
- Unified diff
- New / updated tests
- Manual verification
- Blast-radius note
- Rollback criteria
- Remaining risk


Failure behavior:
If the evidence still does not justify a specific patch, say "Root cause not yet stable" and recommend the next diagnostic artifact needed.

REFACTOR — Spell of Safe Refactoring

REFACTOR.M — Minor cast

You are acting as a senior software engineer performing behavior-preserving refactoring.


Refactor the code below to improve clarity or reduce duplication without changing public behavior.


Code:
[PASTE CODE]


Constraints:
[PASTE API, PERFORMANCE, OR COMPATIBILITY CONSTRAINTS]


Return:
1. Invariants to preserve
2. Refactored code
3. Why behavior should be unchanged
4. Quick test ideas


Do not rename public interfaces unless explicitly allowed.

REFACTOR.W — Working cast

You are acting as a maintainer producing a reviewable refactor Patch Bundle.


Inputs:
- Relevant files: [PASTE]
- Public API or behavior guarantees: [PASTE]
- Existing tests or examples: [PASTE]
- Constraints: [PASTE]


Requirements:
- preserve current behavior
- reduce duplication, complexity, or ambiguity
- keep the diff reviewable
- do not smuggle in unrelated cleanups


Output contract:
Return:
1. Refactor objective
2. Invariants to preserve
3. Unified diff
4. Revised code
5. Suggested or updated tests
6. Risks to inspect during review


If behavior-preserving refactoring is not possible without more context, name the missing context.

REFACTOR.R — Ritual cast

You are acting as a staff engineer performing a production-safe refactor.


Inputs:
- Files to refactor: [PASTE]
- Public behavior and interface guarantees: [PASTE]
- Existing tests, benchmarks, and operational constraints: [PASTE]
- Hard constraints: [PASTE]


Procedure:
1. Define the refactor objective.
2. Enumerate behavior, interface, and performance invariants.
3. Identify the minimum surfaces to change.
4. Produce the refactor.
5. Add or update tests that prove key invariants still hold.
6. Note any watchpoints where a reviewer should be especially skeptical.


Output contract:
Return a Patch Bundle with:
- Refactor objective
- Invariants preserved
- Files changed and rationale
- Unified diff
- Updated code
- Tests or verification plan
- Review watchpoints
- Rollback note


Failure behavior:
If the code is too entangled for a safe refactor from the provided context, say so and recommend a smaller refactor slice.

TEST — Spell of Test Forging and Verification

TEST.M — Minor cast

You are acting as a software test engineer.


Create the most valuable tests for the change or behavior below.


Behavior or diff:
[PASTE SPEC / CODE / DIFF]


Stack / test framework:
[PASTE STACK]


Return:
1. Test cases ordered by value
2. Test code
3. Edge cases still uncovered


Prefer small tests with clear failure meaning.

TEST.W — Working cast

You are acting as a senior engineer producing a Verification Bundle.


Inputs:
- Spec Card or behavior target: [PASTE]
- Code or diff under test: [PASTE]
- Existing tests and framework context: [PASTE]
- Risk areas or past regressions: [PASTE IF AVAILABLE]


Requirements:
- map tests to acceptance criteria or observed risks
- include happy path, edge cases, and regression paths
- identify what cannot be proved from unit tests alone
- prefer robust tests over brittle implementation-coupled tests


Output contract:
Return:
1. Test strategy
2. High-value test matrix
3. Test code
4. Manual checks if needed
5. Remaining gaps


If more environment or fixture context is needed, list the minimum missing pieces.

TEST.R — Ritual cast

You are acting as a principal verification engineer producing a production-grade Verification Bundle.


Inputs:
- Spec Card and/or Design Brief: [PASTE]
- Code or unified diff: [PASTE]
- Existing tests, fixtures, and environment details: [PASTE]
- Operational, performance, or security constraints: [PASTE]


Procedure:
1. Translate acceptance criteria and risks into test obligations.
2. Partition tests into unit, integration, regression, and manual checks.
3. Cover edge cases, invalid inputs, boundary sizes, concurrency or retry behavior if relevant.
4. Identify what cannot be established from the available environment.
5. Provide a concise verification checklist for human review or CI.


Output contract:
Return a Verification Bundle with:
- Verification strategy
- Risk-to-test mapping
- Unit tests
- Integration or end-to-end tests
- Manual verification checklist
- Gaps and limits
- Recommended next spell


Failure behavior:
If the behavior target is ambiguous, stop and point back to DISTILL or DESIGN.

API — Spell of Contract and Interface Design

API.M — Minor cast

You are acting as an API designer.


Design the cleanest contract for the requirement below.


Requirement:
[PASTE SPEC OR REQUEST]


Existing conventions:
[PASTE STACK / API STYLE / DOMAIN RULES]


Return:
1. Proposed endpoint or interface
2. Request / input shape
3. Response / output shape
4. Error cases
5. One example request and response


Prefer simplicity and consistency with the existing system.

API.W — Working cast

You are acting as a senior interface designer producing a Contract Sheet.


Inputs:
- Spec Card: [PASTE]
- Existing API or interface conventions: [PASTE]
- Auth, compatibility, or versioning constraints: [PASTE]
- Domain rules or data model notes: [PASTE]


Requirements:
- define the contract clearly enough for implementation and testing
- include validation and error behavior
- note idempotency or retry semantics where relevant
- respect versioning and backward-compatibility constraints


Output contract:
Return:
1. Contract purpose
2. Endpoint / function / event definition
3. Request schema or input contract
4. Response schema or output contract
5. Validation rules
6. Error taxonomy
7. Auth / authorization expectations
8. Examples
9. Compatibility notes


If a key domain rule is unclear, ask the smallest question needed to resolve it.

API.R — Ritual cast

You are acting as a principal API architect preparing a production-ready Contract Sheet.


Inputs:
- Spec Card: [PASTE]
- Existing contracts or public API conventions: [PASTE]
- Auth model, security constraints, and compatibility requirements: [PASTE]
- Data model / workflow context: [PASTE]


Procedure:
1. Restate the contract goal.
2. Define the surface area and caller responsibilities.
3. Specify input and output schemas.
4. Define validation, auth, authorization, and error behavior.
5. State idempotency, pagination, retry, and rate-limit behavior if relevant.
6. Provide examples.
7. Note observability and backward-compatibility obligations.


Output contract:
Return a Contract Sheet with:
- Contract purpose
- Public surface definition
- Input schema
- Output schema
- Validation rules
- Error taxonomy
- Auth / authorization model
- Idempotency / retry semantics
- Examples
- Observability notes
- Compatibility / migration notes
- Recommended next spell


Failure behavior:
If required domain or compatibility rules are missing, say exactly what is needed before this contract should be implemented.

MIGRATE — Spell of Safe Data and Schema Migration

MIGRATE.M — Minor cast

You are acting as a database-minded engineer.


Outline the safest migration strategy for the change below.


Change:
[PASTE SCHEMA OR DATA CHANGE]


Context:
[PASTE DB / SERVICE / TRAFFIC / DEPLOYMENT CONTEXT]


Constraints:
[PASTE DOWNTIME, COMPATIBILITY, OR RISK CONSTRAINTS]


Return:
1. Migration strategy
2. Prechecks
3. Main steps
4. Validation checks
5. Rollback idea


Prefer reversible steps over clever ones.

MIGRATE.W — Working cast

You are acting as a senior engineer producing a Migration Runbook.


Inputs:
- Current state: [PASTE CURRENT SCHEMA / DATA SHAPE / FLOW]
- Target state: [PASTE TARGET SHAPE]
- Traffic and deployment context: [PASTE]
- Data volume and correctness constraints: [PASTE]
- Existing rollback limits or operational windows: [PASTE]


Requirements:
- prefer expand / migrate / contract or an equally safe staged approach
- avoid data loss
- define prechecks and parity checks
- define rollback before cutover
- note any application changes needed alongside the migration


Output contract:
Return:
1. Strategy summary
2. Preconditions
3. Step-by-step migration
4. Validation and parity checks
5. Cutover conditions
6. Rollback plan
7. Risks and watchpoints


If the migration is unsafe with the current information, say what must be learned first.

MIGRATE.R — Ritual cast

You are acting as a production migration lead writing a high-safety Migration Runbook.


Inputs:
- Current schema / data flow: [PASTE]
- Target schema / data flow: [PASTE]
- Application behavior and compatibility context: [PASTE]
- Data size, traffic shape, and SLO constraints: [PASTE]
- Hard safety constraints: [PASTE]


Procedure:
1. Define invariants that must never be violated.
2. Choose a staged migration pattern.
3. Specify prechecks.
4. Define schema, code, and backfill steps.
5. Define parity validation and observability during the transition.
6. Define cutover criteria.
7. Define rollback triggers and rollback steps.
8. Note communication and on-call implications if relevant.


Output contract:
Return a Migration Runbook with:
- Migration goal
- Invariants
- Chosen strategy
- Preconditions and prechecks
- Step-by-step execution plan
- Backfill or dual-write considerations
- Validation / parity checks
- Cutover criteria
- Rollback triggers and rollback steps
- Operational watchpoints
- Recommended next spell


Failure behavior:
If the migration cannot be made safe from the provided inputs, do not bluff. State the blocking unknowns.

OPTIMIZE — Spell of Performance Tuning by Evidence

OPTIMIZE.M — Minor cast

You are acting as a performance engineer.


Identify the most likely bottlenecks and the best first measurements for the problem below.


Symptom:
[PASTE LATENCY / CPU / MEMORY / COST ISSUE]


Context:
[PASTE WORKLOAD, STACK, AND RELEVANT CODE]


Return:
1. Likely bottlenecks
2. First measurements or profiling steps
3. Candidate optimizations
4. What not to optimize yet


Do not optimize by taste.

OPTIMIZE.W — Working cast

You are acting as a senior performance engineer producing a measurement-first optimization plan.


Inputs:
- Performance symptom and target: [PASTE]
- Current evidence (benchmarks, traces, profiles, metrics): [PASTE]
- Relevant code or architecture: [PASTE]
- Constraints: [PASTE]


Requirements:
- distinguish measured bottlenecks from plausible ones
- propose the smallest benchmark or profiling setup that would sharpen the decision
- recommend optimization candidates in expected-value order
- note regression risks and guardrails


Output contract:
Return:
1. Target metric and goal
2. Current evidence summary
3. Highest-probability bottlenecks
4. Benchmark / profiling plan
5. Candidate optimizations
6. Regression risks
7. Recommended next spell


If there is not enough measurement data to justify code changes, say so.

OPTIMIZE.R — Ritual cast

You are acting as a principal performance engineer preparing a performance intervention that can survive review.


Inputs:
- Target metric and SLO: [PASTE]
- Current measurements, traces, profiles, or load data: [PASTE]
- Relevant code, data structures, and architecture: [PASTE]
- Hard constraints: [PASTE]


Procedure:
1. Restate the performance problem.
2. Separate measured bottlenecks from hypotheses.
3. Define the benchmark or profiling methodology.
4. Rank intervention candidates by expected impact and risk.
5. If enough evidence exists, propose a concrete patch direction.
6. Define how regression will be checked.


Output contract:
Return:
- Performance problem statement
- Current evidence
- Confirmed vs hypothesized bottlenecks
- Benchmark / profiling plan
- Optimization candidates ranked by impact
- Candidate patch direction
- Regression guardrails
- Recommended next spell


Failure behavior:
If the evidence is not strong enough to justify touching code, recommend the exact measurement artifact to gather next.

HARDEN — Spell of Security Review and Hardening

HARDEN.M — Minor cast

You are acting as a software security reviewer.


Review the material below for likely vulnerabilities or dangerous assumptions.


Material:
[PASTE CODE / DESIGN / CONFIG / FLOW]


Context:
[PASTE THREAT MODEL, AUTH, DATA SENSITIVITY, EXPOSURE]


Return:
1. Likely security issues
2. Why each matters
3. Quick remediation ideas
4. What needs deeper review


Be concrete: name attack paths, not just buzzwords.

HARDEN.W — Working cast

You are acting as a senior security engineer producing a Threat Table.


Inputs:
- Code, diff, design, or config: [PASTE]
- Trust boundaries and exposure context: [PASTE]
- Auth / authorization model: [PASTE]
- Data sensitivity and operational constraints: [PASTE]


Requirements:
- identify plausible exploit paths
- prioritize by impact and ease of abuse
- distinguish confirmed findings from suspicion
- recommend minimally disruptive remediations where possible


Output contract:
Return:
1. Threat summary
2. Threat Table with columns: finding, exploit path, severity, affected surface, remediation
3. Immediate fixes
4. Deeper follow-up checks
5. Recommended next spell


If the material is too incomplete for a real review, say what artifact is missing.

HARDEN.R — Ritual cast

You are acting as a principal security engineer performing a production-grade review.


Inputs:
- Code, diff, design, infrastructure, or config material: [PASTE]
- Trust boundaries, entry points, and caller model: [PASTE]
- Authentication / authorization model: [PASTE]
- Data classification, secrets handling, and compliance constraints: [PASTE]


Procedure:
1. Identify attack surfaces and trust boundaries.
2. Evaluate input handling, authn/authz, secrets, data exposure, logging, and dangerous side effects.
3. Consider injection, SSRF, traversal, deserialization, replay, privilege escalation, and abuse of retries or queues where relevant.
4. Distinguish confirmed findings from concerns requiring more evidence.
5. Recommend remediations and verification checks.


Output contract:
Return a Threat Table package with:
- Security summary
- Trust boundaries
- Threat Table (finding, exploit path, severity, evidence, remediation)
- Immediate blocking issues
- Medium-priority hardening work
- Verification checks for remediations
- Recommended next spell


Failure behavior:
If the artifact set is incomplete, state exactly what missing surface prevents a trustworthy review.

GATE — Spell of Review, Release, and Go/No-Go Decisions

GATE.M — Minor cast

You are acting as a strict but fair code reviewer.


Review the change below and decide whether it is ready for the next step.


Change:
[PASTE DIFF / SUMMARY / PATCH BUNDLE]


Context:
[PASTE SPEC, RISK NOTES, AND TEST RESULTS]


Return:
1. Blocking issues
2. Important but non-blocking issues
3. What evidence is still missing
4. Go / no-go recommendation


Be specific and actionable.

GATE.W — Working cast

You are acting as a release-minded senior engineer producing a Go/No-Go Memo.


Inputs:
- Spec Card or intended behavior: [PASTE]
- Patch Bundle or diff: [PASTE]
- Verification Bundle / tests: [PASTE]
- Migration, security, or performance notes: [PASTE IF AVAILABLE]
- Rollout and rollback notes: [PASTE]


Requirements:
- judge against the stated objective, not personal taste
- separate blockers from follow-ups
- note missing evidence
- make a clear recommendation


Output contract:
Return:
1. Change summary
2. Blockers
3. Non-blocking concerns
4. Missing evidence
5. Rollout watchpoints
6. Go / no-go recommendation
7. Required next spell if not ready


Do not say "looks good" without explaining why.

GATE.R — Ritual cast

You are acting as a release gate reviewer making an auditable ship decision.


Inputs:
- Spec Card and/or Design Brief: [PASTE]
- Patch Bundle: [PASTE]
- Verification Bundle: [PASTE]
- Migration Runbook / Threat Table / Perf Report as relevant: [PASTE]
- Rollout and rollback plan: [PASTE]


Procedure:
1. Check whether the change satisfies the intended behavior.
2. Check whether key risks have corresponding evidence.
3. Identify blockers, missing evidence, and watchpoints.
4. Judge release readiness, not abstract code beauty.
5. State what would change the decision if currently blocked.


Output contract:
Return a Go/No-Go Memo with:
- Decision summary
- Objective fit
- Evidence reviewed
- Blocking issues
- Non-blocking issues
- Missing evidence
- Rollout watchpoints
- Rollback readiness
- Final recommendation
- Required next spell


Failure behavior:
If the evidence set is too incomplete to judge responsibly, say "Insufficient release evidence" and list what is missing.

INCIDENT — Spell of Incident Command and Stabilization

INCIDENT.M — Minor cast

You are acting as an incident commander.


Triage the live issue below and give the safest first moves.


Incident data:
[PASTE ALERTS, SYMPTOMS, TIMELINE, LOGS]


Constraints:
[PASTE CUSTOMER IMPACT, SLO, CHANGE FREEZE, OR ACCESS LIMITS]


Return:
1. Current situation summary
2. Likely blast radius
3. First three actions
4. Rollback or mitigation triggers
5. What evidence to gather next


Optimize for stabilization first.

INCIDENT.W — Working cast

You are acting as a senior incident lead producing an Incident Decision Log.


Inputs:
- Timeline and symptoms: [PASTE]
- Alerts, logs, traces, metrics: [PASTE]
- Recent deploys / config changes: [PASTE]
- Operational constraints: [PASTE]


Requirements:
- separate confirmed facts from working hypotheses
- recommend stabilizing actions before deep diagnosis when needed
- define evidence requests for the next round
- note rollback or escalation triggers


Output contract:
Return:
1. Situation summary
2. Confirmed facts
3. Working hypotheses
4. Immediate actions
5. Evidence to gather next
6. Rollback / mitigation triggers
7. Recommended next spell


Keep the tone operational and calm.

INCIDENT.R — Ritual cast

You are acting as an incident commander producing a structured Incident Decision Log for a live software event.


Inputs:
- Timeline, symptoms, and current customer impact: [PASTE]
- Alerts, logs, traces, metrics, dashboards, and recent changes: [PASTE]
- System architecture or runbook context: [PASTE]
- Operational constraints and decision authority limits: [PASTE]


Procedure:
1. Reconstruct the situation from verified facts.
2. Estimate blast radius and urgency.
3. Separate stabilization actions from deeper diagnosis.
4. Define evidence requests for narrowing the cause.
5. Define rollback, mitigation, escalation, and communication triggers.
6. Recommend the next spell in the stack.


Output contract:
Return an Incident Decision Log with:
- Situation summary
- Customer / system impact
- Confirmed facts
- Working hypotheses
- Immediate stabilization actions
- Evidence requests
- Rollback / mitigation triggers
- Escalation triggers
- Communication note for stakeholders
- Recommended next spell


Failure behavior:
If the evidence is chaotic or contradictory, say so and prioritize evidence-preserving stabilization steps.

SCRIBE — Spell of Explanation, Documentation, and Runbooks

SCRIBE.M — Minor cast

You are acting as a technical writer with engineering judgment.


Explain the material below in a way another engineer can use.


Material:
[PASTE CODE / DIFF / DESIGN / INCIDENT NOTES]


Audience:
[PASTE AUDIENCE]


Return:
1. What this thing does
2. How it works at a high level
3. Important caveats
4. When someone should be careful


Make it practical, not literary.

SCRIBE.W — Working cast

You are acting as an engineer-documentarian producing durable internal documentation.


Inputs:
- Code, design, or system artifact: [PASTE]
- Audience and purpose: [PASTE]
- Operational context, commands, dashboards, or dependencies: [PASTE]
- Known pitfalls: [PASTE IF AVAILABLE]


Requirements:
- explain the system in the order a practitioner needs it
- include the minimum commands or procedures needed to work safely
- note common failure modes and where to look when things go wrong


Output contract:
Return:
1. Overview
2. How it works
3. Key interfaces or dependencies
4. How to operate or change it safely
5. Troubleshooting notes
6. Open risks or caveats


Prefer concise operational clarity.

SCRIBE.R — Ritual cast

You are acting as a production-minded technical writer creating an operator-grade runbook.


Inputs:
- System, service, code, or incident artifact: [PASTE]
- Audience and operational setting: [PASTE]
- Commands, dashboards, dependencies, alerts, and recovery knowledge: [PASTE]
- Known failure modes or recent lessons: [PASTE]


Procedure:
1. Explain the system's purpose and boundaries.
2. Describe normal operation.
3. Describe safe change procedures.
4. Describe troubleshooting and common failure modes.
5. List commands, dashboards, logs, and rollback actions.
6. Note what is still undocumented or fragile.


Output contract:
Return a Runbook with:
- Purpose and scope
- Architecture / dependency sketch
- Normal operation
- Safe change procedure
- Monitoring and dashboards
- Common failure modes
- Troubleshooting steps
- Recovery / rollback steps
- Caveats and undocumented edges
- Recommended next spell


Failure behavior:
If key operational knowledge is missing, do not fake it. Mark the gap explicitly.

DECOMPOSE — Spell of Recursive Decomposition

DECOMPOSE.M — Minor cast

You are acting as a planning-oriented software lead.


Break the goal below into the smallest useful engineering tasks.


Goal:
[PASTE GOAL OR SPEC]


Context:
[PASTE SYSTEM / TEAM / TIME CONTEXT]


Return:
1. Main subtasks
2. Dependencies
3. What can happen in parallel
4. First two tasks to do now


Keep the tasks bounded and concrete.

DECOMPOSE.W — Working cast

You are acting as a staff engineer building a Work Tree for AI-assisted execution.


Inputs:
- Spec Card or large objective: [PASTE]
- Architecture / codebase context: [PASTE]
- Constraints and deadlines: [PASTE]
- Global invariants or non-negotiables: [PASTE]


Requirements:
- decompose until each leaf task is small enough for one bounded implementation or diagnostic spell
- keep dependencies explicit
- separate parallelizable work from sequential work
- preserve global invariants so recomposition is safe


Output contract:
Return:
1. Global objective
2. Invariants to preserve
3. Task tree
4. Dependency order
5. Parallelizable branches
6. Suggested spell for each leaf
7. Integration checkpoints


If the scope is still too vague, point back to DISTILL first.

DECOMPOSE.R — Ritual cast

You are acting as a principal engineer constructing a recursive execution plan for a large software objective.


Inputs:
- Spec Card and/or Design Brief: [PASTE]
- System and team context: [PASTE]
- Hard constraints, delivery boundaries, and non-negotiable invariants: [PASTE]


Procedure:
1. Restate the global objective.
2. Enumerate invariants that must hold across all subwork.
3. Recursively decompose the work into bounded leaves.
4. Assign a likely spell family to each leaf.
5. Define integration checkpoints and recomposition risks.
6. Define what constitutes completion at each level.
7. Recommend where loops are likely and where recursion should stop.


Output contract:
Return a Work Tree with:
- Global objective
- Global invariants
- Recursive task tree
- Spell recommendation per leaf
- Dependency graph in prose
- Integration checkpoints
- Recomposition risks
- Exit conditions for each layer
- Recommended next spell


Failure behavior:
If the objective mixes incompatible scopes or undefined constraints, say so and recommend a DISTILL or DESIGN pass before further decomposition.

Stack controller

You are coordinating a software spell stack.


Stack seal: [PASTE STACK SEAL]
Current stage: [PASTE SPELL.SEAL.LEVEL]
Overall objective: [PASTE OBJECTIVE]
Exit condition: [PASTE EXIT CONDITION]
Iteration budget if looped: [PASTE NUMBER OR "n/a"]


Carry forward only validated facts from prior artifacts.
At the end of this stage, return:
1. The artifact for this stage
2. The recommended next stage
3. Whether the stack should continue, loop, recurse, escalate, or stop


Artifacts so far:
[PASTE PRIOR ARTIFACTS]

Stack recipes

FEATURE-RAIL

• Form: Gated linear stack with a local build/verify loop
• Sequence: DISTILL.W → DESIGN.W → FORGE.W → TEST.W → GATE.W
• Artifact flow: Spec Card → Design Brief → Patch Bundle → Verification Bundle → Go/No-Go Memo
• Loop / recursion rule: If tests fail or acceptance criteria are only partially met, loop FORGE.W ↺ TEST.W until the Verification Bundle satisfies the spec or the attempt budget is exhausted.
• Exit condition: Exit when the Go/No-Go Memo says go, or when the missing evidence or blockers are clear enough for a human decision.

BUG-LOOP

• Form: Looped diagnostic-and-repair stack
• Sequence: DIAGNOSE.W → PATCH.W → TEST.W → GATE.M
• Artifact flow: Fault Tree → Patch Bundle → Verification Bundle → Go/No-Go Memo
• Loop / recursion rule: Repeat the whole loop until the bug disappears under verification, the hypothesis ranking stops improving, or the iteration budget is reached. If root cause confidence drops, re-run DIAGNOSE.W before touching the patch again.
• Exit condition: Exit on verified fix, escalation, or evidence stagnation.

REFACTOR-RAIL

• Form: Gated linear stack with a preservation loop
• Sequence: REFACTOR.W → TEST.W → GATE.W
• Artifact flow: Patch Bundle → Verification Bundle → Go/No-Go Memo
• Loop / recursion rule: If invariants or behavior checks fail, loop REFACTOR.W ↺ TEST.W until invariants hold or the refactor slice must be reduced.
• Exit condition: Exit when the review says behavior is preserved and the remaining risk is understood.

MIGRATION-RITE

• Form: High-safety gated stack
• Sequence: DISTILL.W → DESIGN.R → MIGRATE.R → TEST.R → GATE.R
• Artifact flow: Spec Card → Design Brief → Migration Runbook → Verification Bundle → Go/No-Go Memo
• Loop / recursion rule: If parity checks fail in rehearsal or staging, loop MIGRATE.R ↺ TEST.R until the mismatch is explained or the plan is redesigned.
• Exit condition: Exit only on a go decision backed by parity checks, rollback readiness, and explicit cutover criteria.

INCIDENT-LOOP

• Form: Live-response loop with documentation tail
• Sequence: INCIDENT.R → DIAGNOSE.W → PATCH.W → GATE.M
• Artifact flow: Incident Decision Log → Fault Tree → Patch Bundle → Go/No-Go Memo → Runbook / Post-incident Note
• Loop / recursion rule: Repeat DIAGNOSE.W → PATCH.W → GATE.M while the incident remains live and the mitigation window is open. When the system stabilizes, cast SCRIBE.W or SCRIBE.R to preserve the lessons.
• Exit condition: Exit on stabilization, rollback, service recovery, or escalation to a deeper human-led response.

FRACTAL-BUILD

• Form: Recursive stack with local leaf loops
• Sequence: DECOMPOSE.R → [for each leaf: DISTILL.W or DESIGN.W → FORGE.W → TEST.W → GATE.M] → GATE.W
• Artifact flow: Work Tree → leaf Spec Cards / Design Briefs → leaf Patch Bundles → leaf Verification Bundles → final Go/No-Go Memo
• Loop / recursion rule: Each leaf may locally loop FORGE.W ↺ TEST.W. The recursion stops when leaves are small enough for one bounded implementation spell.
• Exit condition: Exit when all leaves clear their local gates and the recomposed system clears the final global gate.