[Decision] Define campaign behavior when expected attachments are missing #75

New Issue

zemion · 2026-07-20T14:44:02+02:00

zemion commented

2026-07-20 14:44:02 +02:00

Problem

The local Campaign WIP contains campaign-wide no-attachment behavior, but missing an expected attachment may be a hard delivery error, a review decision, an excluded recipient, or an allowed omission. The system must apply one effective policy consistently and must not guess silently.

Decisions Needed

Which modes ship: block, ask/review, drop recipient, warn and continue, or another explicit policy?
What is the canonical precedence between campaign-wide, validation-policy, attachment-rule, and recipient-specific behavior?
Who may select permissive behavior or override review, and are a reason and separation of duties required?

Acceptance Criteria After Decision

Campaign configuration names the effective policy, source/precedence, and delivery consequence.
Build/review distinguishes no attachment expected, expected-but-missing, unreadable, policy-excluded, and resolution failure.
A frozen campaign version records the effective campaign and per-rule policy and each per-message outcome.
Queue, bulk send, single-send, resend, and retry paths cannot bypass a blocking/review outcome.
Overrides record actor, authority, reason, timestamp, and affected recipients/messages.
Reports/protocol show aggregate and per-message outcomes without exposing unrelated file data.
Tests cover every mode, mixed recipients, persistence/API paths, rebuild invalidation, authorization, review reasons, retries, and evidence.

Audited Local State (2026-07-20)

The WIP is a partial implementation base, not complete:

Five zero-coverage modes, per-rule overrides, build states, persisted issue snapshots, reports, and queue guards exist. Focused attachment/ZIP tests pass.
attachments.missing_behavior is exposed in the UI but ignored by the resolver, which inherits validation_policy; a configured block can therefore resolve to warn.
An optional-missing block can yield validation ok=true while the built job is blocked.
Unreadable files are not distinguished from generic resolution/build failures.
Review evidence records actor/time but no reason or explicit override authority; normal editors can select permissive modes.
Execution policy evidence omits the campaign-wide and per-rule missing behavior.
Mixed-recipient, authorization, persistence/API, rebuild, bypass, and evidence coverage is still missing.

Do not close or integrate this as finished until the policy contract is accepted and these contradictions are removed in isolated commits.

## Problem The local Campaign WIP contains campaign-wide no-attachment behavior, but missing an expected attachment may be a hard delivery error, a review decision, an excluded recipient, or an allowed omission. The system must apply one effective policy consistently and must not guess silently. ## Decisions Needed - Which modes ship: `block`, `ask/review`, `drop recipient`, `warn and continue`, or another explicit policy? - What is the canonical precedence between campaign-wide, validation-policy, attachment-rule, and recipient-specific behavior? - Who may select permissive behavior or override review, and are a reason and separation of duties required? ## Acceptance Criteria After Decision - [ ] Campaign configuration names the effective policy, source/precedence, and delivery consequence. - [ ] Build/review distinguishes no attachment expected, expected-but-missing, unreadable, policy-excluded, and resolution failure. - [ ] A frozen campaign version records the effective campaign and per-rule policy and each per-message outcome. - [ ] Queue, bulk send, single-send, resend, and retry paths cannot bypass a blocking/review outcome. - [ ] Overrides record actor, authority, reason, timestamp, and affected recipients/messages. - [ ] Reports/protocol show aggregate and per-message outcomes without exposing unrelated file data. - [ ] Tests cover every mode, mixed recipients, persistence/API paths, rebuild invalidation, authorization, review reasons, retries, and evidence. ## Audited Local State (2026-07-20) The WIP is a partial implementation base, not complete: - Five zero-coverage modes, per-rule overrides, build states, persisted issue snapshots, reports, and queue guards exist. Focused attachment/ZIP tests pass. - `attachments.missing_behavior` is exposed in the UI but ignored by the resolver, which inherits `validation_policy`; a configured `block` can therefore resolve to `warn`. - An optional-missing `block` can yield validation `ok=true` while the built job is blocked. - Unreadable files are not distinguished from generic resolution/build failures. - Review evidence records actor/time but no reason or explicit override authority; normal editors can select permissive modes. - Execution policy evidence omits the campaign-wide and per-rule missing behavior. - Mixed-recipient, authorization, persistence/API, rebuild, bypass, and evidence coverage is still missing. Do not close or integrate this as finished until the policy contract is accepted and these contradictions are removed in isolated commits.

zemion commented

2026-07-20 16:46:00 +02:00

A code-and-test audit on 2026-07-20 confirms this is only partially implemented locally. The mechanics are promising, but the visible/canonical policy can disagree and governance/evidence paths remain incomplete. The issue stays status/needs-info; the audited gaps are now in the body.

A code-and-test audit on 2026-07-20 confirms this is only partially implemented locally. The mechanics are promising, but the visible/canonical policy can disagree and governance/evidence paths remain incomplete. The issue stays `status/needs-info`; the audited gaps are now in the body.

zemion referenced this issue

2026-07-20 17:12:17 +02:00

[Bug] Review attachment links overflow without scroll or detail access #59

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan-campaign#75