Synthetic write-canary enrollment cannot dispatch the first observed import

[lamemustafa]

Evidence

The local synthetic-fixture enrollment is intentionally non-mutating, but no native command dispatches an import. The write authorization path requires capability Observed, while the first canary is meant to establish that observation. The result is a bootstrap dead-end: write capability stays Unknown forever.

Impact

Bridge cannot perform its first controlled local Tally write despite the approved local enrollment workflow.

Acceptance criteria

• Add a sealed, single-ledger CREATE canary only for an active, fresh, GUID-bound synthetic enrollment.
• Require explicit synthetic/no-customer-data/backup attestations and preview-bound confirmation.
• Permit Unknown -> Observed only after one no-retry import, strict success counters, and exact company-bound readback of the Bridge-owned remote identity.
• Persist only redacted durable outcome evidence; uncertainty after dispatch must remain OutcomeUnknown and block retry.
• Reject rename and optional-field-clearing alterations until their documented semantics and exact readback are implemented.
• Add simulator coverage for success, partial/error counters, duplicate/ambiguous readback, stale enrollment/review, and timeout-after-send.

Security impact

This must not create generic Tally write access, expose payloads/responses, or weaken loopback, fixture, consent, or no-retry controls.

[lamemustafa]

Additional verified scope for the first canary:

• Official Tally XML guidance documents ledger create as <LEDGER Action="Create"><NAME>…</NAME><PARENT>…</PARENT></LEDGER>.
• The current renderer has a NAME attribute but does not emit child <NAME>, so the first canary must correct and test that documented create form before any live dispatch.
• The same guidance confirms rename alters identify the existing ledger in the NAME attribute and carry the replacement as child <NAME>; current code uses the proposed name as the attribute.
• Optional-field Some → None remains unsupported and must be rejected until explicit documented clear semantics are qualified.

Source: https://help.tallysolutions.com/sample-xml/ and https://help.tallysolutions.com/article/DeveloperReference/integration-capabilities/case_study_1.htm/

No live request or raw Tally data was used for this finding.