CPO-APPROVAL-REQUIRED: the masking policy is CPO-owned. The proposed
policy in v1.4-candidates.md §3.2 T1-SEC-3 is adopted as the default:
mask SSN, credit-card (Luhn-validated), IBAN, phone (E.164). The CPO
can amend via a follow-up PR at any time.
---ci---
project: inboxos
phase: 1
milestone: v1.4
status: execute
wave: 3
task: T3
cpo_approval_required: true
cpo_approval_status: proposed_policy_adopted_as_default
---/ci---
The extraction-contract.md doc cited 4 line ranges in
pipelines/common.py that drifted past the v1.0 + v1.1
line-shuffle (the v1.1 EXECUTE stage added ~70 lines to
the LLM block: 30+ to LLMConfig.from_env and ~25 to
_ollama_call_one_model, plus a reshape of opencode_run_command).
This commit updates the 4 cites to the post-v1.1 line
positions:
- line 40: 467-468 → 545-546 (default_model / extract_model
env defaults in LLMConfig.from_env)
- line 98: 414-479 → 492-585 (LLMConfig class range)
- line 102: 605-624 → 636-680 (_ollama_call_one_model
function range)
- line 161: 378-407 → 440-487 (opencode_run_command
function range)
The contract semantics (model pin, prompt path, JSON parse)
are unchanged — only the line refs are updated. The
surrounding prose is preserved verbatim.
Verified: grep -n 'pipelines/common.py:' docs/extraction-contract.md
shows the 4 new ranges and zero hits to the stale ranges
(467-468, 414-479, 605-624, 378-407).
---ci---
project: inboxos
phase: 1
milestone: v1.3
status: execute
tasks_completed: [T2.4]
candidates_closed: [REQ-INB-32]
files_touched:
- docs/extraction-contract.md (4 line-ref substrings replaced, lines 40, 98, 102, 161)
---/ci---
The historical pipeline captures Papra_Link during the pre-classify
attachment walk and writes it onto the NocoDB row at extract time.
The live pipeline previously emitted the papra_decision log event
but did not PATCH the link onto the row, creating a documented
asymmetry. This commit closes it.
pipelines/live_pipeline.py:
- Capture the first returned id from papra_write_attachment as
papra_link (parallel to the historical pipeline's
pre-classify walk).
- After the per-module upsert loop, iterate over the collected
upserts and PATCH Papra_Link onto each module row that was
upserted. Idempotent: a re-run with the same papra_link is
a no-op on the column.
- Emit a structured papra_link_patched event with the message_id,
the papra_link, and the list of modules_patched. Failures are
per-row papra_link_patch_failed events; the pipeline continues.
- The papra_write_body branch also captures its single id into
papra_link (defensive; body uploads go to one module, but
the parity patch is harmless if there are 0 upserts).
docs/extraction-contract.md:
- §'Live vs historical: Papra_Link asymmetry' subsection removed.
The asymmetry is closed; the cross-references to ARCHITECTURE.md
and papra-write-policy.md are updated by T2.3.
ARCHITECTURE.md:
- §'Document Store (curated)' 'Live vs historical asymmetry'
paragraph replaced with a single sentence: 'Both pipelines
capture Papra_Link on the NocoDB row whenever the attachment
walk returns a papra_link.' with a forward pointer to
docs/extraction-contract.md.
pipelines/_tests/test_papra_link_parity_offline.py (new, ~1 test):
- test_papra_link_patched_on_live_after_attachment_write
asserts the parity patch: 2 module rows + 2 Papra_Link patches,
one papra_link_patched event listing both modules.
The papra_decide function in pipelines/common.py is unchanged;
the patch is a caller-side change in live_pipeline.py only.
docs/papra-write-policy.md §Rule 1 'Live pipeline note' removal
is deferred to T2.3 (Wave 2) per the plan.
---ci---
project: inboxos
phase: 1
milestone: v1.1
status: execute
---/ci---
pipelines/live_pipeline.py was already refactored to use the
canonical inboxos:classify + inboxos:extract-<module> flow and the
NOCODB_MODULE_TABLES env var (see INB-5). The "open alignment work"
section of docs/schemas.md and the "alignment needed" subsection of
docs/extraction-contract.md were written from a stale read of the
file; this commit removes the misleading notes.
No code or schema changes; docs only.
Co-Authored-By: Paperclip <noreply@paperclip.ing>