accrete-kit 0.0.0-stage → 0.1.0

package/dist/scaffold/assets/template/.accrete/docs/long-term-work.md

@@ -0,0 +1,108 @@
+# Accumulating useful work
+
+ACCRETE is most useful when the next session can begin from the code, products,
+capabilities, and understanding that earlier work made available. Retention is a
+selective act of project judgment. It can happen during work or after its value
+becomes apparent.
+
+## Preserve the right distinction
+
+| What is changing | Suitable durable description | What stays native |
+|---|---|---|
+| A numerical program develops | Model identity and meaningful iteration outcomes | Repository commits, branches, builds, and execution |
+| A diagnostic becomes worth reusing | Tool purpose, source, and exposure | Scripts, compiled code, examples, and domain explanation |
+| A product is selected for future use | Data meaning, origin, content description, and locations | Native scientific files and storage |
+| An activity produces observations | Result with the operands and context actually known | Detailed logs, traces, arrays, and external tracking systems |
+| Understanding changes | Memory explaining the interpretation and its conditions | Authored reasoning and native text search |
+
+These can occur at different times. An experiment can run before its Result is
+recorded. A script may remain temporary until a later task reveals a recurring
+purpose. A new interpretation can be written long after the original run. No
+single object needs to carry all of those changes.
+
+## Continue from prior work
+
+Read the relevant Result and Memory before deciding whether further execution is
+useful. The observations describe the code, Tools, Data, and conditions they
+name. Preserve them when a Model advances; their historical context remains
+meaningful.
+
+A changed project commit may concern documentation only. A changed comparator or
+mapping can affect an interpretation even when the Model is unchanged. The
+Agent and domain Tools decide what matters to reuse. ACCRETE has no universal
+rule equating commit equality with scientific equivalence or commit difference
+with a required rerun.
+
+When further work is justified, name the uncertainty it resolves. It might be a
+new mechanism question, a changed operand, a missing product, or a new computing
+environment. The useful Result then explains the actual activity and its
+observations without pretending it speaks for unrelated revisions or conditions.
+
+## Let capability grow through practice
+
+Keep a one-off analysis script in ordinary source or Scratch while it is still
+being developed. When it has a recurring purpose, retain the code and the
+knowledge required to use it. The Tool may contain scripts, compiled programs,
+reference material, or prose alone. Admit it through the Kernel when it should
+have a project identity.
+
+A Skill is one discovery interface for that capability. Expose it when automatic
+discovery helps. It can also be used directly by path or by another program.
+Keep the Tool's editable source distinct from generated host wrappers. Run `tool
+refresh` when its description or binding changes; code edits still happen with
+normal development tools.
+
+Record the implementation used for a particular activity when known. An
+admission-time commit on a live Tool does not automatically identify the code a
+later run executed. Selecting a retained revision requires actual matching
+material; a label alone cannot freeze a mutable directory.
+
+## Keep knowledge understandable
+
+Useful Memory explains how an observation changed the understanding of a
+problem, why a choice was made, which conditions limit it, and what could help
+next. Write in normal prose. Do not turn every command, transcript, or transient
+machine observation into a Memory entry.
+
+If a later explanation changes, append a new entry linking the earlier one and
+the relevant Results. Explain what changed and why. Preserve the earlier
+interpretation in the conditions in which it was made. Dated Markdown and stable
+IDs provide continuity without controlling the style of the explanation.
+
+As a topic becomes difficult to navigate, author a useful synthesis and link its
+supporting entries and Results. A Tool can contain a durable method distilled
+from several such experiences. The project does not require an automatic
+summarizer, embedding index, or scoring system before it can benefit from Memory.
+
+## Retain meaning without copying every byte
+
+Data registration can describe a large remote product in place. Keep compact
+diagnostics or reduced tables close to analysis while preserving the locations
+of raw outputs or restart states that are worth retaining. Content digests,
+provider versions, and manifests have their own scopes; use what is known and
+worth computing for the task.
+
+Two products with identical bytes can have different scientific roles. Preserve
+both meanings. A corrected closed product normally receives a new Data ID, naming
+the earlier one in `replaces`, so old Results continue to refer to the input or
+output they actually used.
+
+Retaining a descriptor does not ensure that a remote path will remain available.
+Use the storage service's actual conditions and the owner's retention choices.
+Before removing working storage, identify the selected material that subsequent
+work needs and preserve it through ordinary source retention, Data locations,
+or an explicitly chosen archive.
+
+## Separate project progress from software upgrades
+
+The Kernel and foundational guidance are versioned releases; Models, Tools, Data, and
+Memory evolve on the project's own schedule. `npx accrete-kit@latest upgrade` brings
+newer foundational assets into this project and moves its Kernel binary.
+`accrete migrate` changes managed document representation.
+None of these advances a Model, revises an earlier interpretation, or declares a
+scientific result obsolete.
+
+Use [the configuration guide](configuration.md) to resolve the active host and
+[the remote guide](remote-work.md) when computation and analysis happen in
+different environments. Preserve the relationships that help the next action;
+let the research continue in the form appropriate to its question.

package/dist/scaffold/assets/template/.accrete/docs/overview.md

@@ -0,0 +1,118 @@
+# Working in an ACCRETE project
+
+ACCRETE gives enduring identities and relationships to the products of ongoing
+computational work. The Agent chooses the question, develops and runs programs,
+interprets what happened, and decides what to retain. The native `accrete` Kernel
+publishes the corresponding managed object changes.
+
+## Start with the current work
+
+Read the owner's request and `.accrete/PROJECT.md`. Search the relevant existing
+code, Results, and Memory with ordinary tools. Load the object Skill that helps
+the next action. There is no required sequence through the five stores and no
+requirement to register an activity before starting it.
+
+Launch the main Claude Code or Codex session from the project root so its
+instructions and Skills are discoverable. Model checkouts, Tool sources, data,
+environments, and run directories may be elsewhere. Pass the owning project
+explicitly to the CLI when operating there; a nested Git root does not establish
+the intended ACCRETE project.
+
+## The object system
+
+| Object | Why it is retained | What changes through the Kernel | Natural working interface |
+|---|---|---|---|
+| Model | A computational program that continues to evolve | Registration, host binding, update, retirement, opening and closing an iteration, removing its worktree | Git, editor, compiler, model runtime |
+| Tool | An ability worth using again, including knowledge and executable work | Admission, host binding, metadata/revision selection, exposure, refresh, retirement, export | Its source directory, native language tools, Skill instructions |
+| Data | An input or product selected for continued use | Registration, amendment, locations, managed materialization and eviction, retirement | Filesystem, storage tools, scientific format readers |
+| Result | A retained account of an activity and its observations | Creation, amendment, appended observations | JSON readers and the local SQLite projection |
+| Memory | Understanding, decisions, experience, and future direction | Publication of complete authored prose and associations | Markdown, file search, ordinary reading |
+
+Scratch is ordinary ongoing work. It can contain scripts, drafts, logs, partial
+outputs, or an entire investigation. Its contents become managed only through a
+chosen object operation. A useful script may become a Tool; a finished output
+may become Data; a completed or failed attempt may become a Result; its lesson
+may become Memory. Each decision can be made independently and retrospectively.
+
+## Relationships that support continuation
+
+A Result can name several Model revisions in different roles, the Tools used,
+input and output Data, and execution conditions. Memory explains how to interpret
+those observations and what they suggest next. A Tool can combine the programs
+and understanding that have repeatedly proved useful in those activities.
+
+Object identity is independent of physical location. A registered Data object
+can exist while its bytes remain remote. A Model can use several worktrees of
+one Git repository. A Tool can have two host discovery interfaces while remaining
+one capability. A Memory filename can change during import while its stable ID
+continues to identify the same entry.
+
+Keep the revision actually used by an activity separate from the current revision
+of its Model or Tool. Today's checkout is useful evidence about today's files;
+it does not fill a missing historical execution revision. Preserve unknown
+information as unknown and retain supplied context without fabricating it.
+
+## Where to work
+
+The defaults place small object descriptors in `.accrete/objects/`, Results in
+`results/`, dated Memory in `memory/`, Tool sources in `tools/`, managed Data
+replicas in the ignored `.accrete/data/`, and ongoing work in the ignored
+`scratch/`. Creating a Workspace writes only `.accrete/project.toml`, the installed
+assets and the ignored Kernel binary at `.accrete/bin/accrete`; store directories appear on first use. Shared `.accrete/project.toml`
+defines logical roots; ignored `.accrete/local.toml` binds this host's paths.
+Configuration can place all of these elsewhere.
+
+Foundational Skills are ordinary directories under `.agents/skills/` for Codex
+and `.claude/skills/` for Claude Code. Each contains concise instructions and
+references to load when needed. Read only the guidance relevant to the action:
+
+| Need | Skill |
+|---|---|
+| Associate or develop a computational implementation | `accrete-models` |
+| Retain, expose, or evolve a reusable capability | `accrete-tools` |
+| Describe, locate, or materialize retained inputs/outputs | `accrete-data` |
+| Preserve an activity, its operands, and observations | `accrete-results` |
+| Carry understanding and decisions into later work | `accrete-memory` |
+
+## The write boundary in practice
+
+Use ordinary tools to clone repositories, edit source, commit changes, run
+simulations, inspect arrays, transfer unregistered working files, and draft
+prose. Use the Kernel when the action establishes or changes ACCRETE identity,
+associations, lifecycle, or a managed location. Scientific programs write their
+own outputs directly. Source and configuration are edited normally; managed
+descriptors, Result publication, and Memory allocation use the CLI.
+
+Use `git`, `rg`, `jq`, `sqlite3 -readonly`, or domain readers for questions those
+tools already answer. `accrete index refresh` repairs or updates the local query
+projection. It does not rerun the activity. A mutation receipt with
+`committed: true` and `index_pending: true` means the object already exists and
+only indexing remains.
+
+Open the index with `sqlite3 -readonly` at the path in `.local_state.index` from
+`accrete config resolve --json`, and inspect `.schema` before assuming table or column
+names. A brief "database is locked" during a concurrent refresh means retry. The projection describes
+its last successful refresh of this metadata view, and does not establish live
+process state or current remote availability.
+
+Read [the CLI contract](cli-contract.md) and [command map](cli-commands.md) before
+a new kind of managed write; `accrete COMMAND --help` prints the flags. When an
+operation stops partway, `accrete recover` finishes it from its receipt. On a host
+without the binary, continue native work and preserve drafts for later submission.
+Do not recreate the Kernel with ad hoc descriptor-writing scripts.
+
+## Further guidance
+
+- [Coordinator responsibilities](coordinator.md): maintain direction, delegate,
+  integrate, and decide what to retain.
+- [Subagent work](subagents.md): concrete briefs, independent working locations,
+  and useful handovers.
+- [Long-term work](long-term-work.md): relationships, reuse, capability growth,
+  and changing interpretations.
+- [Configuration](configuration.md): project context, path bindings, and local
+  state.
+- [Remote work](remote-work.md): computation and metadata exchange across hosts.
+
+These manuals and Skills come from the npm generator `accrete-kit`;
+`.accrete/release.json` names the version that installed them. Installing a different
+Kernel does not rewrite this guidance or migrate project documents. `npx accrete-kit@latest upgrade` and `accrete migrate` handle those distinct changes.

package/dist/scaffold/assets/template/.accrete/docs/remote-work.md

@@ -0,0 +1,125 @@
+# Working across machines
+
+Use ordinary SSH, transfer tools, domain launchers, and site schedulers for remote
+computation. The Kernel is needed on the host where managed metadata writes occur. It is
+one native executable that runs without Node.js. ACCRETE does not need a remote coordinator
+service.
+
+## Establish the working context
+
+Share the project's small configuration and documents through its normal Git or
+explicit transfer arrangement. A remote clone has the same project identity and
+its own ignored `.accrete/local.toml`, local metadata-view index, and operation
+state. Native Model repositories may be obtained separately and bound to the
+appropriate Models with `accrete model bind` on that host; `accrete tool bind` does
+the same for Tool source.
+
+`.accrete/bin/` is ignored by Git, so each clone restores its own Kernel. With Node on the
+host, run this at the Workspace root, using `template_version` from `.accrete/release.json`:
+
+```sh
+npx accrete-kit@<version> install
+```
+
+On a host without Node, take the archive for that host from the `accrete-cli` GitHub Release
+at `kernel_version` from `.accrete/release.json`, and extract it into the Workspace:
+
+```sh
+mkdir -p .accrete/bin
+tar -xzf accrete-<version>-<target>.tar.gz --strip-components=1 -C .accrete/bin
+```
+
+Name the actual Model revisions, input locations, execution directory, domain
+Tool, and current resource constraints in the assignment. Supply the relevant
+project guidance explicitly when a worker starts from an external Model checkout.
+An environment and its import paths remain the concern of the Tool launching the
+program.
+
+## Compute and retain at the useful boundaries
+
+Scientific execution writes ordinary files in its working directory. A useful
+activity can be recorded before, during, or after execution; that choice does not
+authorize or schedule the computation. A Result may describe a failed launch,
+one completed leg, a partial chain, or a full activity.
+
+Register closed products when the producer has completed the relevant writes.
+For a continuing campaign, a completed year's restart and diagnostics can be
+retained while later years are still running. A preallocated history file or a
+directory's presence does not establish that its scientific product is finished.
+If a live source is intentionally registered, describe it as mutable.
+
+Reduce large arrays near the computation when the question benefits from smaller
+products. Retain raw outputs or restart states at the location chosen for them,
+and give reduced products their own Data descriptions and origin associations.
+Transfer only the material needed for the current analysis. Data registration
+does not compel copying or hashing every member of a large remote tree.
+
+## Bring back portable descriptions
+
+Exchange Result JSON, Data/Model/Tool descriptors, and selected Memory through
+ordinary Git, or as a metadata bundle when no shared remote exists:
+
+```sh
+accrete export --to handoff.json --id RESULT_ID --id MEMORY_ID
+accrete import --from handoff.json
+```
+
+Omit `--id` to export every managed document. A bundle carries documents, IDs,
+revisions and Memory paths. It leaves out scientific payloads, Git objects, Tool
+source and machine bindings. Preserve supplied IDs and historical revisions. Do not
+copy the remote live SQLite database as the durable project description; refresh a
+local projection from the received documents.
+
+An unresolved relation is acceptable when the referenced repository or Data is
+still remote. A Memory filename collision between independent hosts does not
+mean the entries are the same; the stable IDs distinguish them and `import`
+allocates the receiving path. Divergent content under one identity is reported as a
+conflict and needs a deliberate merge, rather than last-writer-wins replacement. To
+replace a predecessor on purpose, add its current byte revision as `expected_revision`
+in that bundle entry.
+
+Import reports each object's outcome and is not atomic. A partial batch exits 7 with
+a nonzero `failed` count, and its successful entries stay committed. Repeating the
+same bundle acknowledges those and completes the rest. A bundle from another project
+needs `--allow-foreign`, which keeps its original project IDs.
+
+## Materialize what analysis needs
+
+Read already available bytes with native readers. To create a managed replica,
+use `data materialize` with a configured source and destination. The Kernel
+handles the location association while a local copy or rclone download performs the
+transfer. Uploads are native rclone work followed by `data location add`. A project
+already using DVC, DataLad, or site transfer software can use that tool and add the
+completed location the same way.
+
+Publication of transferred bytes and publication of the location description are
+separate completion points. If one completes without the other, run `accrete
+recover` on that host: it finishes publication from the receipt and reports an
+incomplete transfer with its paths for explicit retry. Do not restart the simulation
+to repair metadata or transfer state.
+
+A local analysis can then produce its own Result and Memory linked to the
+original remote products. This retains the relationship between production,
+reduction, and interpretation without demanding one universal campaign layout.
+
+## Current state comes from the system that owns it
+
+A copied Result describes what its author observed. It does not establish that
+a remote process is still running or that a path remains available now. Use the
+scheduler, process table, logs, or domain launcher for current execution state.
+Use native storage access for present availability when the task needs it.
+
+Keep metadata writers on one host for a shared writable metadata view. Separate
+host-local locks do not coordinate simultaneous writers to the same NFS tree.
+Payload files can remain on shared storage under the scientific program's own
+I/O conditions, while metadata travels through the chosen explicit arrangement.
+
+## Hand over enough to continue
+
+Name the activities actually completed, relevant code revisions and runtime
+context, Result and Data IDs, concrete retained paths, and outstanding work.
+State what remains only on the remote host and which products are already
+available for analysis. Preserve useful source or selected outputs before
+removing their temporary worktree with `accrete model iteration remove-worktree` or
+their execution directory with ordinary tools. Let the owner's task
+determine the format and extent of the handover.

package/dist/scaffold/assets/template/.accrete/docs/subagents.md

@@ -0,0 +1,78 @@
+# Working as an ACCRETE subagent
+
+Work on the delegated question using the host's normal tools. Your useful
+contribution may be code, a diagnostic, a reduction, a capability, an explanation,
+or a concrete unresolved observation. ACCRETE provides a way to retain selected
+products; it does not prescribe how to investigate the question.
+
+## Reconstruct the necessary context
+
+Identify the owning ACCRETE project and the actual editable checkout or path.
+Read the instructions relevant to that location and the supplied Tool Skill.
+If you start outside the project root, read its `AGENTS.md` and
+`.accrete/PROJECT.md` explicitly; discovery in another Git repository may expose
+a different instruction set.
+
+Use the designated Model revision and environment when the assignment names
+them. A shell working directory, Git HEAD, and an installed Python package can
+point to different implementations. When execution identity matters, obtain it
+from the domain launcher or actual runtime context. Keep an unavailable historical
+revision unknown instead of substituting today's HEAD.
+
+Search the relevant Memory rather than loading every entry. Use retained work
+under its stated conditions. No general rule requires repeating earlier work
+before you can use it.
+
+## Work within the assigned context
+
+Keep overlapping edits in your assigned worktree or disjoint directory. Do not
+switch a shared checkout's branch while another worker is using it. Read-only
+input data can remain shared. Follow the current resource allocation and make
+new resource needs visible to the Coordinator when they affect other work.
+
+Use native Git, editors, scientific libraries, shell, SSH, and schedulers for
+the substantive task. Temporary scripts and observations may remain in Scratch.
+Do not promote every helper to a Tool or every intermediate array to Data.
+Retain them when there is a continuing purpose.
+
+An ACCRETE iteration belongs to the actual Model repository. A worktree supplied
+by the agent host may instead isolate the project repository. Use the explicit
+Model binding and paths in the brief; do not infer they are equivalent.
+
+## Publish when it is part of the assignment
+
+Use `accrete` to publish managed objects. Draft structured input or Memory
+prose in an ordinary working file, then submit it. You can record useful failed
+or partial activity, retain external references, and admit work retrospectively.
+Missing local payloads do not require fabricating a completed computation.
+
+Keep the command's returned object IDs, revisions, paths, and any pending effects
+in the handover. If only indexing remains, the object has already committed.
+If a transfer, worktree or publication stopped partway, run `accrete recover` and
+report what it finished. If an amendment conflicts with another writer, retain your
+draft and reconcile the specific changes with the current document or Coordinator.
+
+Do not edit shared managed descriptors or SQLite directly. On a host without the
+binary, continue native work and hand over the prepared draft with the specific
+command it needs.
+
+## Return a useful handover
+
+Explain what happened and where the concrete material is. Include the actual
+revisions, result/data IDs, relevant observations, and remaining questions that
+matter to integration. Describe important behavior changes in a Tool so the next
+action can load the updated source; a refresh of files does not erase already
+loaded instructions from another session.
+
+A handover can be a few sentences. For example:
+
+> The reduction program is committed on the assigned branch at the revision
+> below. It reads the completed first-year output without changing that tree.
+> The reduced table is at the named remote path and its Data ID is attached.
+> The second year's input is still being produced, so only the first year's
+> observations are described in the Result. I left the draft interpretation
+> beside the table for integration with the comparison worker's findings.
+
+Fill the concrete references from your work. Do not create a task card or
+administrative report merely to fit this example. Before removing a temporary
+worktree, return or retain the selected source and products needed later.

package/dist/scaffold/assets/template/.accrete/examples/README.md

@@ -0,0 +1,78 @@
+# Input drafts
+
+These files are reusable caller-input drafts for the `accrete` commands. They are
+reference assets installed with the project guidance. **They are not existing
+ACCRETE objects, initial store contents, or instructions to execute a research
+workflow.** `npx accrete-kit@latest create` copies them as examples; it does not submit them.
+
+Copy a useful draft into the configured Scratch directory, adapt it to the
+actual work, and submit it only when the corresponding organizational action
+is intended. Replace example descriptions and every `REPLACE_WITH_...` value.
+Use IDs returned by earlier Kernel writes and actual Git revisions. Empty
+association arrays mean no associations have been supplied; populate them only
+with objects relevant to the activity. Omit fields that are unknown.
+
+The installed [CLI contract](../docs/cli-contract.md) describes the fields, and the
+[command map](../docs/cli-commands.md) lists every operation. Read the matching
+Skill reference for the object's meaning.
+
+## Available drafts
+
+| Draft | Submit with | Adapt before submission |
+| --- | --- | --- |
+| [model-register.json](model-register.json) | `model register --from FILE` | Choose the program name and existing checkout. `repository.checkout` is the same as `--checkout`. Add top-level `source_scope` only when it describes the program meaningfully. |
+| [iteration-open.json](iteration-open.json) | `model iteration open MODEL_ID --from FILE` | Supply the question, starting revision, and intended worktree. `existing: false` creates that worktree; `true` attaches one already there; omitting `worktree` allocates no storage. Flags of the same names override these fields. |
+| [iteration-close.json](iteration-close.json) | `model iteration close ITERATION_ID --from FILE --expect REVISION` | Describe the actual outcome and include relevant commits when known. Closing does not integrate or remove worktrees. |
+| [tool-admit.json](tool-admit.json) | `tool admit --from FILE` | Name the useful capability and its existing editable source. |
+| [tool-update.json](tool-update.json) | `tool update TOOL_ID --from FILE --expect REVISION` | Supply only the intended JSON Merge Patch fields. |
+| [tool-retire.json](tool-retire.json) | `tool retire TOOL_ID --from FILE --expect REVISION` | Explain why the Tool should leave normal discovery. The same optional document works for `model retire` and `data retire`. |
+| [data-register.json](data-register.json) | `data register --from FILE` | Describe the intended content and replace the borrowed location. Registration does not copy or hash its payload. |
+| [result-record.json](result-record.json) | `result record --from FILE` | Describe the actual activity and supplied execution information; populate known associations. |
+| [result-amend.json](result-amend.json) | `result amend RESULT_ID --from FILE --expect REVISION` | Express the actual correction against the current descriptor revision. |
+| [observation.md](observation.md) | `result observe RESULT_ID --text-file FILE` | Write the independent observation and useful context. |
+| [memory-entry.md](memory-entry.md) | `memory append --from FILE` | Write complete understanding in ordinary prose and supply relevant relation flags. |
+
+The uppercase command terms represent values to supply. Prepend global
+`--project DIRECTORY` when outside the intended project and `--json` when consuming
+a mutation receipt. `ACCRETE_PROJECT` provides the project-selection fallback.
+
+## Association shapes
+
+Result inputs accept these association shapes, populated with actual stable
+IDs rather than aliases or paths:
+
+| Field | Member shape |
+| --- | --- |
+| `models` | `{ "model_id": ID, "role": ROLE, "commit": COMMIT_OR_NULL, "dirty": BOOLEAN_OR_NULL }` |
+| `tools` | `{ "tool_id": ID, "revision": REVISION_OR_NULL }` |
+| `inputs`, `outputs` | `{ "data_id": ID, "role": ROLE }` |
+| `related_results` | `{ "result_id": ID, "role": ROLE }` |
+| `observations` | `{ "text": TEXT }`, with any further domain fields |
+
+Roles are optional authored descriptions. Unknown execution revisions can be
+omitted or null. A retrospective activity does not inherit the current checkout
+HEAD. A Data origin can carry a known `result_id`, and `memory append` takes
+repeatable `--model`, `--tool`, `--data`, `--result`, and `--supersedes` flags.
+Objects referenced from another host can remain unresolved locally.
+
+## Drafts and managed publications
+
+The Kernel supplies the persistent envelope, publication path, stable identity,
+revision handling, and projection update. A caller-supplied `id` on a create draft
+is an optional retry aid, not an instruction to fabricate earlier objects: 1-180
+ASCII letters, digits, dots, underscores or hyphens, and not `.` or `..`. Memory
+input is a Markdown body with no Kernel-owned frontmatter. The Kernel adds its ID,
+authored metadata, and associations on publication.
+
+`tool-update.json` and `result-amend.json` use JSON Merge Patch. Objects merge
+recursively, arrays replace entire arrays, and null removes a key. Identity,
+kind, and format fields cannot be changed through these ordinary patches.
+Read current content before constructing a patch that replaces an array. Keep
+the expected revision corresponding to that read.
+
+`.accrete/contracts/input-drafts.schema.json` documents caller payload shapes, and
+`.accrete/contracts/example-inputs.json` maps these files to its definitions. They
+are not required at runtime. They do not describe the persisted document envelope,
+allocate identities, prove that a checkout exists, establish scientific completeness,
+or grade the research. Unknown project extension fields remain allowed. The CLI
+supplies mechanical validation and actual publication behavior.

package/dist/scaffold/assets/template/.accrete/examples/data-register.json

@@ -0,0 +1,19 @@
+{
+  "name": "selected-output",
+  "description": "Describe the selected completed product and its intended use.",
+  "content": {
+    "kind": "directory",
+    "mode": "closed"
+  },
+  "origin": {
+    "description": "Describe the producer, extraction, or provider of this material."
+  },
+  "locations": [
+    {
+      "name": "producer-output",
+      "kind": "filesystem",
+      "path": "REPLACE_WITH_EXISTING_OUTPUT_PATH",
+      "managed": false
+    }
+  ]
+}

package/dist/scaffold/assets/template/.accrete/examples/iteration-close.json

@@ -0,0 +1,5 @@
+{
+  "outcome": "retained_separately",
+  "summary": "Replace with the actual outcome and any useful reason for retaining this line of work.",
+  "commits": []
+}

package/dist/scaffold/assets/template/.accrete/examples/iteration-open.json

@@ -0,0 +1,8 @@
+{
+  "name": "numerical-investigation",
+  "purpose": "Describe the question or implementation change this effort develops.",
+  "branch": "numerical-investigation",
+  "worktree": "REPLACE_WITH_NEW_WORKTREE_PATH",
+  "start": "HEAD",
+  "existing": false
+}

package/dist/scaffold/assets/template/.accrete/examples/memory-entry.md

@@ -0,0 +1,10 @@
+# Understanding to retain
+
+Replace this text with complete understanding that later work should use.
+Explain the relevant observation or decision, why it matters, the scope of the
+interpretation, and any useful continuation. Link the actual objects through
+the append flags and readable prose where appropriate.
+
+Choose the structure and language that fit the subject. A correction can name
+the earlier interpretation and explain what changed. Do not add Kernel-owned
+frontmatter or allocate a publication filename in this draft.

package/dist/scaffold/assets/template/.accrete/examples/model-register.json

@@ -0,0 +1,7 @@
+{
+  "name": "simulation-model",
+  "description": "Describe the computational program developed or used by this project.",
+  "repository": {
+    "checkout": "REPLACE_WITH_EXISTING_CHECKOUT"
+  }
+}

package/dist/scaffold/assets/template/.accrete/examples/observation.md

@@ -0,0 +1,9 @@
+# Observation
+
+Replace this text with the independent observation to append. State what was
+observed, when or under which conditions that matters, and the concrete material
+needed to understand it. Include units or comparison definitions when useful.
+
+Use ordinary prose suited to the activity. The observation can describe partial
+progress, a failure, an additional measurement, or useful context; no fixed
+outcome or section structure is required.

package/dist/scaffold/assets/template/.accrete/examples/result-amend.json

@@ -0,0 +1,5 @@
+{
+  "execution": {
+    "description": "Replace with the intended corrected or additional execution description."
+  }
+}

package/dist/scaffold/assets/template/.accrete/examples/result-record.json

@@ -0,0 +1,11 @@
+{
+  "name": "short-activity-label",
+  "activity": "Describe the actual activity to retain.",
+  "models": [],
+  "tools": [],
+  "inputs": [],
+  "outputs": [],
+  "execution": {},
+  "observations": [],
+  "related_results": []
+}

package/dist/scaffold/assets/template/.accrete/examples/tool-admit.json

@@ -0,0 +1,8 @@
+{
+  "name": "diagnostic-method",
+  "description": "Describe the useful capability and the context in which to use it.",
+  "source": {
+    "path": "REPLACE_WITH_EXISTING_TOOL_SOURCE",
+    "mode": "live"
+  }
+}

package/dist/scaffold/assets/template/.accrete/examples/tool-retire.json

@@ -0,0 +1,3 @@
+{
+  "reason": "Describe why this Tool should leave normal discovery."
+}

package/dist/scaffold/assets/template/.accrete/examples/tool-update.json

@@ -0,0 +1,3 @@
+{
+  "description": "Replace with the intended revised capability description."
+}

package/dist/scaffold/assets/template/.gitattributes

@@ -0,0 +1,17 @@
+# accrete:begin
+AGENTS.md text eol=lf
+CLAUDE.md text eol=lf
+.accrete/*.md text eol=lf
+.accrete/*.toml text eol=lf
+.accrete/docs/** text eol=lf
+.accrete/config-examples/** text eol=lf
+.accrete/contracts/** text eol=lf
+.accrete/examples/** text eol=lf
+.accrete/release.json text eol=lf
+.accrete/template-install.json text eol=lf
+# Base and candidate digests cover their exact bytes on every checkout.
+.accrete/template-bases/** -text
+.accrete/template-upgrades/** -text
+.agents/skills/accrete-*/** text eol=lf
+.claude/skills/accrete-*/** text eol=lf
+# accrete:end