Qualify Journal posting against concurrent external Tally changes

[lamemustafa]

The Journal posting work in #236 (also used by #238) verifies company, date/profile, ledger bindings and prior-voucher absence through separate reads. Bridge's queue and per-user endpoint lease serialize Bridge writers; they do not prevent changes made by another Tally user or importer between those observations and the import.

This tracks the two remaining admission review findings as one external-concurrency qualification problem. Moving each check to the end in turn cannot establish a mutation-time guarantee. A potential wrong-ledger or unsupported-date result must not be represented as safe concurrent posting.

On 8 September 2026 the owner accepted the quiet-company first version: pause other edits and imports, and keep the company and Tally mode unchanged until Bridge finishes. The native approval displays this condition in e67d3b0, shared by MCP and desktop. The two review findings are accepted workflow limitations for this preview, not fixed races or proof of concurrent-editor safety. This issue stays open for stronger concurrent-editor support and is not a blocker to the accepted preview. Gold remains a deployment profile rather than a blanket prohibition; Education retains operation-specific date rules.

Acceptance for concurrent-editor support:

• Establish and document a supported Tally-side conditional import or equivalent authoritative witness covering company, relevant masters, date/profile and candidate identity at mutation time. Separate read ordering is insufficient.
• Verify the mechanism on owned synthetic books with controlled external changes; retain full responses and exact readback. Do not change an operator's licence or settings as an incidental test.
• Demonstrate that changed assumptions refuse before mutation, and that timeout/unknown outcomes retain original-batch reconciliation without resend.
• Qualify applicable Gold/Education/version behavior individually, recording unavailable platform evidence explicitly.
• Preserve one shared MCP/desktop dispatch implementation and the existing accounting-success checks. No new generic mapper or arbitrary XML tool is required by this issue.

The current official import-event documentation excludes Start Import and Import Object events from HTTP imports. Its Empty attribute is a research candidate, not an established atomicity or rollback mechanism: https://help.tallysolutions.com/how-to-use-import-file-definition-and-related-events/ .

Related review: #236 (comment) and #236 (comment). General rectification tracking remains #237. No merge or release is authorized by this issue.

[lamemustafa]

Backlog disposition: deferred concurrent-editor support remains with the product integration task. The accepted quiet-company preview limitation remains in force and is not a claim of concurrency safety. Next action, when this separate scope is authorized, is to establish an authoritative mutation-time witness or equivalent Tally-side mechanism before implementing stronger support, then qualify controlled external changes and unknown-outcome reconciliation. No new posting or live probe is part of this backlog audit.

[lamemustafa]

Delivered by #615 (merged as c984dd9): design item 1, compare master marks before the POST.

• The binding snapshot. Inside the endpoint queue, Bridge now reads every loaded company's change marks just before the catalogue re-read. The target's master AlterID (ALTMSTID) in that snapshot must equal the one in the post_import aims its write by company name only; a change before the POST can land the voucher in another company #574 aim snapshot sent last before the POST.
• Refusals, both before the dispatch intent:
  • any change, including a mark that went down, refuses as post_masters_moved;
  • if the comparison can't be made, it refuses as post_masters_unconfirmed.
• What doesn't count: other companies' masters, the target's voucher mark, and a year-split sibling.
• Cost: one extra unpaired request per post.
• Approval wait: a ledger renamed and replaced under its old name during the approval wait was already refused by the (name, GUID) catalogue binding (import_masters_changed). A test now shows it.
• Aim check: Refuse a post when the company's masters moved after the queue's re-read (#239) #615 also tests the post_import aims its write by company name only; a change before the POST can land the voucher in another company #574 aim check's GUID half, which was untested before.

What it catches: only changes that move ALTMSTID.

• Measured: gateway ledger renames and master creates (TALLY_PROTOCOL_REFERENCE §11c.5, §10).
• Not yet measured: a regroup, an edit made in Tally's own screens, and whether posting a voucher moves ALTMSTID. The tool description, the agent README and ADR 0004 follow-up 8 say exactly this.

Next, in its own PR: build-time GUID binding. The saved batch records ledger names only, so a ledger renamed and replaced between build and post is not caught yet.

Still open on this issue:

• re-checking amendments before import;
• the flag after the POST (posted_under_changed_masters);
• the ADR 0004 amendment naming the remaining window and the absence of a mutation-time witness;
• the lab measurements: does a regroup move ALTMSTID; resolving a ledger to its GUID over XML; and the remaining concurrency measurements.

[lamemustafa]

Lab measurement, 2026-09-23: a posted voucher's ledger lines carry no ledger GUID over XML.

Setup:

• Licensed TallyPrime 7.1 Silver, one read-only request.
• A synthetic company, and one Bridge-posted Journal with two ledger lines.
• The request was Bridge's own verification read over that one day, with the ledger-entry fetch widened to ALLLEDGERENTRIES.* (every field).

Result:

• Each ledger line returned 22 non-empty fields.
• The only reference to the ledger was LEDGERNAME.
• The only ID-like tag was OLDAUDITENTRYIDS (value -1).
• No ledger GUID, master ID or other master reference appeared on the line.

Consequence for #239. A check after the POST can't read which ledger master a line posted into. It has to resolve the line's name through a fresh ledger catalogue read.

Confidence: partial. One voucher, one book, one release, and the default field set only. A TDL expression computed on each line was not tried.

[lamemustafa]

Status, 2026-09-23: the #239 detection work is merged. The issue stays open for the lab measurements and two code follow-ups listed below.

Tally still offers no conditional import, so this issue's first acceptance criterion, a mutation-time witness, can't be met as written. What has shipped instead is a set of checks that refuse before sending, plus a check after the POST that stops a doubtful post from reading as verified. ADR 0004's amendment of 2026-09-23 records what is checked and which windows remain.

Delivered

PR	What it does
#607 (the #574 aim)	The last request before the POST confirms the target company's name and GUID: post_company_scope_changed / post_company_scope_unconfirmed
#615	Refuses if the target's master AlterID (ALTMSTID) moves between the queue's catalogue re-read and that last request: post_masters_moved / post_masters_unconfirmed
#616	Each ledger's (name, GUID) is recorded at build, and a post refuses a ledger now on another GUID: import_masters_changed_since_build; an unbound batch refuses as import_batch_predates_ledger_binding
#617	Documents what an amendment compares, and that it compares at build, not at import
#620	Refuses to build an amendment of a voucher altered since Bridge first verified it, by fields and ALTERID: voucher_altered_since_verified / voucher_never_verified
#623	The check after the POST: unless the master mark is proven unmoved, the approved ledgers are resolved again. A changed ledger gives posted_under_changed_masters, and an unconfirmed check gives masters_after_post_unconfirmed. Either is reconciliation_required, never posted_verified, and the doubt persists for later readbacks. It also amends ADR 0004 for concurrent writers
Related: #613	Posts only into a single-currency book: import_multi_currency_unsupported

Measured live: a posted voucher's ledger lines carry only LEDGERNAME (the comment above, R-2). That is why the check after the POST resolves names through the catalogue.

Remaining

Lab, owner's window (synthetic companies, with no client-derived copy loaded):

• W-1: does a regroup move ALTMSTID? Unmeasured. Refuse a post when the company's masters moved after the queue's re-read (#239) #615 catches only changes that move it.
• W-2: does a duplicate voucher number under Manual numbering with Prevent Duplicates give a loud, in-band refusal?
• W-3: does an import without REFERENCE keep or clear one a person added? This decides whether an amendment must carry the REFERENCE.
• R-3: does REFERENCE come back in the verification read? Needed before the amendment compare can include it.

Owner sitting (hand edits in Tally's own screens):

• Does a UI edit move the voucher's ALTERID? Refuse an amendment of a voucher altered since Bridge first verified it (#239) #620 assumes it does, and only gateway alterations are measured (§9.3).
• Does a UI master edit move ALTMSTID? Only gateway renames and creates are measured (§11c.5).

Owner-gated:

• R-4: how often ALTMSTID moves on a working book, which sets Refuse a post when the company's masters moved after the queue's re-read (#239) #615's false-refusal rate. This needs consent to read a client book.

Deferred:

• L3: a concurrent long import alongside a read from two clients. It breaks the one-request-at-a-time rule by design, and needs an explicit exception and an abort plan.

Code follow-ups:

• An explicit operator acknowledgement for a doubted post, through the native approval dialog ("I reviewed this voucher in Tally"), recording who and when. Today a doubt has no clear in Bridge, by design, and the acknowledgement must never be something an agent can call.
• The amendment compare including REFERENCE, once R-3 and W-3 are measured.
• Hands-free amendments (posted natively through the queue rather than imported by hand), now approved by the owner. That closes the build-to-import window in ADR 0004 window 4. A design is being written before any code.