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

New Issue

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

zemion added the area/api codex/needs-human module/campaign

labels 2026-07-29 14:15:03 +02:00

zemion commented

2026-07-30 14:37:26 +02:00

Product decision: accepted

The initial contract is now fixed:

No matching attachment rule means no attachment is expected. This state must never warn or block merely because the message has zero attachments.
A matching required rule with no usable result blocks delivery.
A matching optional rule with no usable result warns and continues.
Unreadable, unsafe, or resolution-failed files are distinct outcomes and block unless an explicit stricter/exception policy says otherwise.
Effective precedence is monotonic: system/tenant Policy floor, campaign policy, rule policy, then recipient-specific tightening. A lower level may tighten but may not silently loosen an inherited requirement.
The first slice does not use implicit drop recipient. Exclusion is an explicit audited action.
Any permitted exception to a required rule needs dedicated authority, reason, actor, timestamp, affected message IDs, and frozen evidence; Policy may disallow exceptions or require separation of duties.
Queue, single-send, resend, and retry consume the same frozen effective outcome.

This resolves the product decision. Implementation can proceed against the existing acceptance criteria.

## Product decision: accepted The initial contract is now fixed: - No matching attachment rule means no attachment is expected. This state must never warn or block merely because the message has zero attachments. - A matching required rule with no usable result blocks delivery. - A matching optional rule with no usable result warns and continues. - Unreadable, unsafe, or resolution-failed files are distinct outcomes and block unless an explicit stricter/exception policy says otherwise. - Effective precedence is monotonic: system/tenant Policy floor, campaign policy, rule policy, then recipient-specific tightening. A lower level may tighten but may not silently loosen an inherited requirement. - The first slice does not use implicit `drop recipient`. Exclusion is an explicit audited action. - Any permitted exception to a required rule needs dedicated authority, reason, actor, timestamp, affected message IDs, and frozen evidence; Policy may disallow exceptions or require separation of duties. - Queue, single-send, resend, and retry consume the same frozen effective outcome. This resolves the product decision. Implementation can proceed against the existing acceptance criteria.

zemion added

status

ready

codex/ready and removed

status

needs-info

codex/needs-human labels 2026-07-30 14:37:56 +02:00

zemion commented

2026-07-30 17:46:44 +02:00

Implemented and pushed in 5f75035.

The effective policy is now monotonic and explicit: no rule means no attachment is expected; required missing attachments block; optional missing attachments warn/review; campaign and validation policy can tighten but not silently loosen a rule. Unreadable, unsafe, missing, ambiguous, and resolution-failure outcomes remain distinct.

Review exceptions require an explicit reason and freeze actor, timestamp, affected job, build identity, message hash, issue fingerprint, and issue codes. Rebuilds invalidate stale review state. Queue, bulk, synchronous, single-message, resend, and retry paths consume the same frozen job state. JSON and CSV reports now include aggregate and per-message exception evidence without exposing unrelated file paths/data.

Verification: the complete Campaign suite passes (289 passed, 16 subtests), and the consolidated module/boundary battery passed.

Implemented and pushed in `5f75035`. The effective policy is now monotonic and explicit: no rule means no attachment is expected; required missing attachments block; optional missing attachments warn/review; campaign and validation policy can tighten but not silently loosen a rule. Unreadable, unsafe, missing, ambiguous, and resolution-failure outcomes remain distinct. Review exceptions require an explicit reason and freeze actor, timestamp, affected job, build identity, message hash, issue fingerprint, and issue codes. Rebuilds invalidate stale review state. Queue, bulk, synchronous, single-message, resend, and retry paths consume the same frozen job state. JSON and CSV reports now include aggregate and per-message exception evidence without exposing unrelated file paths/data. Verification: the complete Campaign suite passes (`289 passed, 16 subtests`), and the consolidated module/boundary battery passed.

zemion closed this issue

2026-07-30 17:46:45 +02:00

zemion commented

2026-07-30 21:48:55 +02:00

Codex State: note

Summary

Decision confirmed: no attachment rule means no attachment is expected; required-and-missing blocks; optional-and-missing warns.
Policy may tighten this behavior but must never silently loosen it.

## Codex State: note ### Summary - Decision confirmed: no attachment rule means no attachment is expected; required-and-missing blocks; optional-and-missing warns. - Policy may tighten this behavior but must never silently loosen it.

zemion commented

2026-07-30 21:50:00 +02:00

Codex State: note

Summary

Decision confirmed: no attachment rule means no attachment is expected; required-and-missing blocks; optional-and-missing warns. Policy may tighten this behavior but must never silently loosen it.

## Codex State: note ### Summary - Decision confirmed: no attachment rule means no attachment is expected; required-and-missing blocks; optional-and-missing warns. Policy may tighten this behavior but must never silently loosen it.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan-campaign#75