NODARAMA VERBATIM — CURRENT RECORDING SHEET REFERENCE & GUIDELINES
0. Introduction
Verbatim is an automated AI code recorder for software development.
It uses RecordingSheets to modify project files through structured, reviewable requests.
This reference defines the request format Verbatim can execute consistently.
Verbatim may be reached through a direct bridge or through the AUX browser extension.

1. Core RecordingSheet JSON Shape
{
Task: "required - descriptive task label", alternates: Diagnostic: ; or Enhancement: ,
Action: "required - supported action name",
FilePath: "required - target path and filename",
Payload: "required - action-specific payload",
Comment: "optional - human-readable note"
}
Task description should be brief but specific: minimal length needed to define the transformation or objective.

Alternative Manifest Labels: Required changes use Task. Optional proposals may use Enhancement or Diagnostic instead.

Enhancement answers: where else should this be deployed or accessed, what else can this do, can this look better or more consistent, or is there a standard feature missing?
Diagnostic answers: what can go wrong, how can this be safer or more flexible, or what would improve compatibility, maintenance, or reliability?

Enhancement and Diagnostic use the same fields as Task: Action, FilePath, Payload, and Comment. Comment should explain why the item is optional. Do not execute unless approved.

2. Recorder Action Set
Eligible actions: newfile, rewritefile, replacestring, replaceall, replaceblock, replacefunction, insertbefore, insertafter, shell
Actions have unique and specific payload requirements, identified in {brackets} and defined below

Action-specific required payloads:
newfile — Payload: { "input": "code/text" } — create a new file.
rewritefile — Payload: { "input": "code/text" } — replace an existing file; fails if missing.
replacestring — Payload: { "target": "locator", "input": "code/text" } — replace the first exact target.
replaceall — Payload: { "target": "locator", "input": "code/text" } — replace every exact target.
replaceblock — Payload: { "start": "locator", "retain": "locator", "input": "code/text" } — replace from start up to, not including, retain.
replacefunction — Payload: { "start": "locator", "input": "code/text" } — replace the full top-level function beginning at start.
insertbefore — Payload: { "find": "locator", "input": "code/text" } — insert input immediately before find.
insertafter — Payload: { "find": "locator", "input": "code/text" } — insert input immediately after find.
shell — Payload: { "command": "shell request" } — policy-gated project-scoped command execution.

Payload Terms: locators must use precise character for character text matches, which can be found in the existing file text exactly. No regex loose matching. 
target = locator; exact text to replace.
find = locator; exact insertion anchor.
start = locator; first text in the replacement range.
retain = locator; first protected text after the replacement range, at least 20 characters, unique. 
input = code/text written by the action.

3. AUX Context Requests
AUX context requests inspect the active project and never execute code changes.
Use AUX context requests for inspection, file reading, search, tree/map, or project context. Use RecordingSheets only for code changes.

[AUXCALL@variable] — returns one project-scoped file as chat context.
[AUXFIND@variable string or function reference] - search term in optional/path — returns function or symbol matches and excerpts.
[AUXSEARCH@variable] -trace query in optional/path — returns text search matches and excerpts.

4. Shell Actions
Shell is a policy-gated RecordingSheet action for project-scoped commands.
Access modes: Deny, Standard, Extended.

Deny — no shell commands permitted.
Standard — only approved command families and argument patterns.
Extended — broader project-scoped shell commands with boundary screening.

Standard allow list: npm ci/install/test/run build/run lint/run format/run; node; python -m pytest/-m venv; pip install; git add/commit/switch/merge; mkdir/move/copy/rename.
Shell may be used for finite project-scoped builds, tests, installs, git actions, file operations, and project-bounded inquiry.
Out-of-scope, unsafe, destructive, evasive, or boundary-escaping commands are rejected or routed for review.

5. Code Writing Format
Use single-line section headers only. Comments are for section dividers, not process commentary.

// filepath/system/index.html
// scope: main page framework for the UI

The first section after the header is unlabeled and may contain imports, constants, setup, registration, or top-level wiring.
Common section headers: // STATES // CONFIG // SETUP // ACTION CHAIN // ACTION CHAIN 2 // RENDER // EVENTS

6. RANGES Roman Alpha Numeric Glyph Encoding Style
RANGES is an optional naming style for compact, targetable identifiers.
Blocks and containers may use a semantic name plus a position/relationship glyph:
Body Ax, Page Bx, Section Cx, Title Do

The capital letter is generally intended to mark indentation/nesting depth. Alternate approaches could be path, branch, or functional family. One approach should be consistently used in a file.
x = container, o = object, s = script step, f = script fork point

Names may use a space or dash depending on file style: Page Bx or Page-Bx.
For scripts, use s or f in place of x or o for process-chain identifiers.
Optional: numbers may be used as the third character to indicate uniqueness, grouping, or script sequence/order.
RANGES reduces repeated class, ID, function, and identifier wording while keeping semantic names short and targetable.
RANGES is flexible style guidance, not a rigid schema. Do not rename existing code into RANGES unless requested or already part of the file’s style.