Skip to content

EXPLAINME.adoc

Latest commit

 

History

History
85 lines (54 loc) · 2.82 KB

EXPLAINME.adoc

File metadata and controls

85 lines (54 loc) · 2.82 KB
Raw

RSR Template Repo - Explainme

Table of Contents

This file explains how the key template claims map to real files.

Central Session Protocol Authority

Claim: Session protocols are centrally maintained and not duplicated in this template.

How this is implemented:

  • The local dispatcher (session/dispatch.sh) maps canonical commands to central protocol paths in standards/session-management-standards.

  • Local files (session/custom-checks.k9, session/local-hooks.sh, coordination.k9) are integration-only.

Caveat:

  • If SESSION_STANDARDS_DIR is unset and no adjacent standards checkout exists, the dispatcher records the command but cannot resolve central checklist paths.

Canonical Command Surface

Claim: Template bindings align to one canonical command model.

How this is implemented:

  • Justfile provides thin aliases (intake-repo, checkpoint-change, verify-maintenance, verify-substantial, verify-release, close-planned, close-urgent, recover-repo, handover-*).

  • Every alias calls session/dispatch.sh with canonical verb-object pairs.

Caveat:

  • Recipes are wrappers only. They do not replace protocol content from the central standards repo.

Runtime State Is Local

Claim: Session state is per-repository runtime output, not standards text.

How this is implemented:

  • session/dispatch.sh writes command and continuity-core capture stubs to .session/LAST-CANONICAL-COMMAND.md in the target repository path.

Caveat:

  • Runtime files are intentionally lightweight and require human/agent completion.

Template Token Policy

Claim: Placeholders are explicit template content until initialization.

How this is implemented:

  • README.adoc and bootstrap recipes keep {{TOKEN}} placeholders visible.

  • just init performs token replacement.

Caveat:

  • Uninitialized placeholders must not be treated as project-specific truth.

Julia Registry Packages — Standalone Repo Requirement

Claim: If this template is used to create a Julia package, it must remain a standalone repository registered with the Julia package registry.

How this is implemented:

  • Julia’s package registry (General.jl or other) expects each package to be a standalone GitHub repository with Project.toml at the repository root.

  • Installation via Pkg.add(), dependency resolution, and automated CI/CD all depend on this canonical structure.

Caveat:

  • Do NOT move this repository into a monorepo or subdirectory, as this breaks registry registration and package discoverability.

  • See JULIA-REGISTRY-REQUIREMENT.md (workspace root) for the complete list of 34 registered Julia packages and enforcement rationale.

  • Non-registry Julia packages can be organized differently if they are not published to any registry.