Recover malformed board scalars

gald3r board recover-scalars repairs a task or bug's malformed title or reason using the exact original value from a Git commit in the same repository. The source record must have the same immutable UUID. The operation preserves status, failure counts, lifecycle versions, history and unselected document bytes. It does not issue a review verdict.

Prepare and preview

Save a JSON request with the record kind, ID and UUID, its current document SHA-256, and the source for each selected field. This is a template; replace each placeholder with observed evidence:

{
  "kind": "task",
  "id": "123",
  "uuid": "<existing record UUID>",
  "expected_before_sha256": "<SHA-256 of current document bytes>",
  "fields": [{
    "field": "title",
    "source_revision": "<full 40-character Git commit>",
    "source_path": ".gald3r/project/tasks/task123_example.md",
    "selector": "heading",
    "value_sha256": "<SHA-256 of the exact selected UTF-8 value>"
  }]
}

The value hash covers the extracted string without an added newline. The heading selector obtains a title from the matching record heading; frontmatter reads a valid scalar, and reason-line recovers an unambiguous historical reason line. Source-free replacement text is not accepted.

gald3r board recover-scalars --request repair.json --json

Inspect the field changes and after_sha256. Set expected_after_sha256 in the request to that exact preview hash before applying.

Apply and finish

gald3r board recover-scalars --request repair.json --apply --json
gald3r board export

Applying a tracked repair requires clean board files and creates a forward Git commit for the recovered record. Checkpoint unrelated board work first. Active controllers, target relocation debt, duplicate records, stale hashes, local divergence and ambiguous source evidence are refused. Investigate the named conflict before preparing a new request; changing a hash alone does not resolve it.

For a reviewed batch, apply each exact request before the final board export. The export settles retained intent and refreshes derived indexes. Confirm the restored values and unchanged lifecycle data, then commit any derived index changes through the normal project workflow.

Before replacing the file, apply saves an exact recovery intent with the original and repaired bytes and their source proof. While it is pending, other changes to that record are refused, including deletion, projection refresh and rebuild. Unrelated records can still change; a bulk rebuild may finish earlier records before reporting the pending-record refusal. Preserve the returned intent ID and phase if interrupted.

Repeat the same request to resume the recorded repair and finish its forward commit, or load the saved request by its applied intent ID:

gald3r board recover-scalars --resume <full intent_id> --apply --json

Use either --request or --resume. Resume accepts no new values or hashes. Use the intent ID from apply or a pending-record refusal. A new preview reports phase=preview and no intent ID; apply creates the durable ID after the reviewed after hash is supplied.

The current file and database must still match the captured original or repaired state. An after hash alone cannot authorize a retry or include unrelated dirty changes. Do not overwrite newer document or database content.

This command accompanies the shared scalar fixes for and. Historical reasons remain historical text; recovering their representation does not grant old approvals or reactivate old gates.