PR !108 was merged by grimacing on 2026-06-10. This document-only
revision updates the v1.5 MINOR status from 'pending Pillar I Gate
approval' to 'Pillar I Gate passed' so the Roadmap stays in lockstep
with the Gitea audit chain.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
- Add Goal 5 (Mailbox & Administrative Management Interface)
- Add Initiative INTV-5 with Epics A-D
- Add MINOR v1.5 to release list
- Record REQ-001 in requirements.md
- Resolve open questions on intake issue #107
Traces to: REQ-001, CIA-79
Co-Authored-By: Paperclip <noreply@paperclip.ing>
- The client is non-technical; the previous guide asked for Pull Requests.
- Rewrote the guide so the only action is 'open a Gitea Issue and paste the template'.
- Added the 'intake' label for SAA discovery.
- Documented SAA post-submission workflow: review → approve → commit to requirements.md → update Issue.
- Pillar I Gate is now an explicit Issue approval comment.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
- Step-by-step guide for submitting requirements via Gitea PR.
- Requirement template block (REQ format) with user story, acceptance criteria,
out-of-scope, and open questions.
- Channel matrix: PR for requirements, Issue for goals/bugs.
- Quick checklist and escalation path.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Retroactive v1 application of the MAJOR Initiative umbrella model per CEO
Option 2 (non-breaking for shipped MINORs; governance enforced moving forward).
- Add ## MAJOR scope declaration: this Roadmap represents the complete
delivery of v1.x.
- Add ## MAJOR Umbrella section: the Gitea umbrella Issue is the single
audit anchor; binding populated on first Pillar I Gate passage.
- Add ## MINOR release list with descriptive names (v1.0 - MVP Foundation,
v1.1 - Beta Cohort, v1.2 - Initial Pipeline Hardening, v1.3 - Stable Cut,
v1.4 - Operator UX + Security Hardening, Backlog). Names are the
canonical form for new Gitea Milestones; legacy Milestones stay intact
(non-breaking) and pick up the major/v1 label.
- Add ## Goals (verbatim, with source links) — drawn from the CPO- and
CTO-authored Gitea Issues; the SAA does not paraphrase.
- Add ## Initiatives (4 Initiatives, 9 Epics): INTV-1 Operator Self-Service,
INTV-2 Security & Compliance, INTV-3 Dual-Approval Governance, INTV-4
Tech-Debt Lane. Each Initiative traces to a stated Goal.
- Add ## Success criteria and ## Out of scope for the MAJOR as a whole.
- Add Sequencing principle 6 (Governance before speed) per INB-328.
- Retain CPO authorship of the milestone timeline; retain the existing
## Milestones, ## Sequencing principles, and ## Change log.
Pillar I Gate pending: this PR is the artifact for the CPO to review and
merge. On merge, the SAA runs SOP §6 to create the major/v1 label, the
MAJOR v1 umbrella Issue, the Backlog Milestone, the release/v1 branch, and
the Initiative/Epic Issue tree (all sub-issues, all with the metadata
matrix populated). The umbrella is blockedBy this PR.
Refs: inboxos#18 (v1.4 IDEATE), inboxos#24 (v1.4.0 re-dispatch / INB-328
P0 governance defect), INB-123 (board mandate initializing the Roadmap),
INB-171 (tooling governance), INB-295 (v1.3.0 recovery), INB-319 (v1.4
IDEATE pre-build), INB-328 (P0 governance defect).
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 runbook §6 section ordering was 6.1 → 6.4 → 6.2 → 6.3
because the v1.1 EXECUTE stage inserted §6.4 "Secret
rotation" (REQ-INB-21, commit 6067008) between §6.1
"Secret inventory" and §6.2 "Why we never commit secrets".
The non-monotonic ordering was filed as v1.1 backlog P1-1
(CI-LOG.md:217-218) and v1.1 explicitly deferred the fix
to a follow-up milestone. v1.2 was a 0/1 disposition so
the carry-forward is v1.3.
This commit restores the monotonic ordering:
- §6.1 Secret inventory (unchanged)
- §6.2 Secret rotation (renumbered from §6.4)
- §6.3 Why we never commit secrets (renumbered from §6.2)
- §6.4 Data-sovereignty posture (renumbered from §6.3)
Plus 4 cross-reference updates in the runbook body:
- line 509: "see §6.4 for the procedure" → "see §6.2 for the procedure"
- line 625: "§6.4 (new in v1.1)" → "§6.2 (new in v1.1, renumbered in v1.3 from §6.4)"
- line 767: "§6.4 documents" → "§6.2 documents"
- line 790: "§5.7 + §6.4" → "§5.7 + §6.2"
Verified: grep -n '^### 6\.' docs/operations-runbook.md
returns 4 sections in 6.1 → 6.2 → 6.3 → 6.4 order.
grep -n '§6\.' docs/operations-runbook.md returns no
stale §6.4 cross-references pointing at the old
"Secret rotation" position.
This commit closes v1.1 backlog item P1-1 (runbook §6
ordering, per CI-LOG.md:217-218).
---ci---
project: inboxos
phase: 1
milestone: v1.3
status: execute
tasks_completed: [T2.5]
candidates_closed: [REQ-INB-36]
backlog_closures:
v1_1_P1_1: REQ-INB-36
files_touched:
- docs/operations-runbook.md (4 heading renumbers + 4 cross-ref updates, lines 509, 511, 561, 568, 625, 767, 790)
---/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---
`docs/papra-write-policy.md:192` and :202 both said "13 cases"
but `pipelines/_tests/test_papra_decide_offline.py` defines 15
test functions. The v1.1 EXECUTE stage added 2 tests
(test_papra_dry_run_override_wins and
test_emit_papra_write_gate_event_logs_three_fields) but the
doc count was not updated. Off-by-2.
This commit updates both lines to "15 cases" to match the
actual test inventory. The 7-bullet list above (attachment
collection, four rule outcomes, HTML body stripping,
classifier-order precedence, dry-run mode, env parsing,
is_configured()) is unchanged — the list still represents
the policy-level coverage, not the test-function count.
---ci---
project: inboxos
phase: 1
milestone: v1.3
status: execute
tasks_completed: [T2.3]
candidates_closed: [REQ-INB-31]
files_touched:
- docs/papra-write-policy.md (2 lines, 192 and 202)
---/ci---
The runbook §4.5 "Forward-pointer" paragraph (lines 285-289)
said "Alerting is out of scope for v1.1; the alert layer is
the next v1.2 deliverable." v1.2 has shipped (tag v1.2.0 on
63c0f59) and was a 0/1 disposition — no alerting deliverable
landed. The forward-pointer was stale.
This commit updates the paragraph to reflect v1.3 reality:
alerting remains out of scope; v1.2 closed on 0/1; the
alert layer is the next v1.x candidate cycle to re-evaluate.
The metrics substrate (REQ-INB-23) is referenced as the
current observability surface. The rest of §4.5 (the
metrics tail snippet at lines 280-283, the opt-out block
at 291-294) is unchanged.
---ci---
project: inboxos
phase: 1
milestone: v1.3
status: execute
tasks_completed: [T2.2]
candidates_closed: [REQ-INB-30]
files_touched:
- docs/operations-runbook.md (1 paragraph, lines 285-289, 5 lines)
---/ci---
The runbook footer (line 823) still said "Next review: after
the v1.1 ship (2026-06-08, milestone `milestone/v1.1-initial`)"
even though v1.1 has shipped, v1.2 has shipped (tag v1.2.0 on
63c0f59), and v1.3 is in the ideate phase on
milestone/v1.3-initial. The footer pointer was stale by 2
milestones.
This commit updates the footer to "Next review: after the
v1.3 ship (2026-06-08, milestone `milestone/v1.3-initial`)"
so the v1.3 audit trail is consistent. The rest of the
footer (the trailing sentence about divergence) is
preserved verbatim.
---ci---
project: inboxos
phase: 1
milestone: v1.3
status: execute
tasks_completed: [T2.1]
candidates_closed: [REQ-INB-29]
files_touched:
- docs/operations-runbook.md (1 line, line 823)
---/ci---
The v1.1 P0 sweep (commits 7c20d5d, d530921) updated the 3
new shell helpers, the runbook, and 2 runbook lines to point
at jc-capital. It missed 2 files:
- docs/gitea-actions.md:95 (last touched at Phase 4 / INB-33,
before the v1.0→v1.1 org migration; the v1.1 sweep was
scoped to .md / .sh created or modified in v1.1)
- scripts/setup_gitea_secrets.sh:4,14,18,28 (pre-existing at
the v1.0 close; not in the v1.1 diff; filed as v1.1 P1-2
for v1.2 follow-up but v1.2 was a 0/1 disposition so the
carry-forward is v1.3)
This commit closes the cto-inboxos owner drift in both files
using the same env-var-resolved default pattern as the v1.1
P0 sweep:
- docs/gitea-actions.md:95 now uses
${GITEA_OWNER:-jc-capital}/inboxos
- scripts/setup_gitea_secrets.sh:4,14 use the same
${GITEA_OWNER:-jc-capital} pattern in the header
- scripts/setup_gitea_secrets.sh:18 defaults
GITEA_OWNER to jc-capital
- scripts/setup_gitea_secrets.sh:28 uses
${GITEA_OWNER:-jc-capital} in the example
Verified: grep -n cto-inboxos docs/gitea-actions.md
scripts/setup_gitea_secrets.sh returns empty. The script is
still chmod +x with set -euo pipefail (unchanged).
This commit also closes v1.1 backlog item P1-2
(setup_gitea_secrets.sh owner drift, per CI-LOG.md:219-220).
---ci---
project: inboxos
phase: 1
milestone: v1.3
status: execute
tasks_completed: [T1.1]
candidates_closed: [REQ-INB-28, REQ-INB-37]
backlog_closures:
v1_1_P1_2: REQ-INB-37
files_touched:
- docs/gitea-actions.md (1 line, line 95)
- scripts/setup_gitea_secrets.sh (4 lines, 4, 14, 18, 28)
---/ci---
P0 from v1.1 multi-persona code review (Pass 1, doc-drift sweep).
The runbook referenced the old cto-inboxos owner at two locations
that the v1.1 work introduced (the §5.1 runner recovery example
and the §10 RTO breakdown) and had a stale 'Next review' footer
that still pointed at the v1.0 Phase 5 close.
- docs/operations-runbook.md:319 §5.1 (Gitea runners API URL)
- docs/operations-runbook.md:792 §10 (Gitea restore push URL)
- docs/operations-runbook.md:823 footer (Next review pointer)
---ci---
project: inboxos
phase: 1
milestone: v1.1
status: review
---/ci---
P0 from v1.1 multi-persona code review (Pass 1, correctness sweep).
The three v1.1-introduced shell helpers (backup.sh, restore.sh,
rotate_secrets.sh) hardcoded the old cto-inboxos owner in the clone URL,
push URL, and default REPO_OWNER. With the org migration to jc-capital
landed at a068c8a, those hardcodes would fail at first invocation:
- scripts/backup.sh:151 clone URL
- scripts/restore.sh:145 push --mirror URL
- scripts/rotate_secrets.sh:32-33 default REPO_OWNER
- scripts/rotate_secrets.sh:101,131 string-literal fallback
The runbook §6.2 service-account line (562) also referenced the old
owner; the runbook lines that are CPO-managed were left alone.
---ci---
project: inboxos
phase: 1
milestone: v1.1
status: review
---/ci---
REQ-INB-15..25 close v1.1 Phase 1. The new §9.4 'v1.1 acceptance
gate' is appended to docs/operations-runbook.md, mirroring the
v1.0 §9.1 + §9.2 structure but only for the 11 new
requirements. Each must-have row cites:
- the REQ-INB-N it satisfies;
- the file:line (or commit SHA, when the line is the test)
that proves it;
- the verification command (where applicable);
- the owner persona.
The 11 candidates are explicitly marked '[CANDIDATE] until the
CPO authors the matching entries in docs/requirements.md'. The
trailing paragraph notes that the .ciagent/inboxos/ROADMAP.md
Phase 1 status row is not flipped by the lead-developer; the
flip is the CPO's call. The PR description in git log reads:
'v1.1 closure: acceptance gate appended; all 11 must-haves
cross-referenced to source'.
No source code is modified by this task; the entire change is
documentation. The 14 v1.1 execution commits (T1.1..T1.7 +
T2.1..T2.5 + T3.1..T3.2) are visible in 'git log --oneline' on
phase/01-v1.1-execute.
---ci---
project: inboxos
phase: 1
milestone: v1.1
status: execute
---/ci---
REQ-INB-22 lands the backup + restore helper and the runbook RTO/RPO.
scripts/backup.sh (new, ~120 lines, set -euo pipefail):
- Accepts a positional argument: nocodb | seaweedfs | gitea.
- nocodb: POST /api/v2/meta/bases/<id>/export to a timestamped
file under backups/nocodb/<ts>/nocodb-export.json.
- seaweedfs: requires SEAWEEDFS_S3_BACKUP_BUCKET and
SEAWEEDFS_S3_BACKUP_ENDPOINT. Mirrors the inboxos bucket to
the backup bucket via 'aws s3 sync' (or boto3 fallback).
Errors with exit code 4 + a clear 'no backup target
configured' message when the env vars are unset.
- gitea: 'git bundle create --all' of the cto-inboxos/inboxos
repo, or 'git clone' + 'git bundle create' fallback.
- Prints the documented one-line summary:
backup_id=<ts> service=<svc> bytes=<int> target=<path>.
scripts/restore.sh (new, ~100 lines, set -euo pipefail):
- Accepts two positional arguments: <backup_id> <service>.
- Verifies the backup directory layout: backups/<svc>/<id>/.
- For nocodb: prints the import instructions (NocoDB has no
server-side import on the free / self-hosted plan; the
operator uses the NocoDB UI to upload the JSON).
- For seaweedfs: reverse-sync from the backup bucket to the
primary bucket via 'aws s3 sync' (or boto3 fallback).
- For gitea: clones the bundle to a temp dir, force-pushes
via the Gitea REST API.
- Prints the documented one-line summary:
restored backup_id=<id> service=<svc> verified=<bool>.
pipelines/_tests/test_restore_offline.py (new, 7 tests):
- All 7 tests pass on the offline test host. The git-bundle
round-trip test pins the integration shape that the
operator's host will exercise end-to-end.
docs/operations-runbook.md:
- New §5.7 'Backup and restore' after §5.6 'Historical pipeline
run cancelled mid-way'. Documents the daily cron, the
retention (7 daily + 4 weekly + 0 monthly), the copy-paste
invocation examples, and the test-or-die gate.
- New §10 'Disaster recovery targets' after §9.3 'Closing the
gate'. States RTO < 4 hours and RPO < 24 hours with the
time-breakdown rationale. Marks the values as explicit and
CPO-acknowledged (the ideation report Tier 2 T2-C flagged
them as 'guesses' pending CPO sign-off; the values recorded
here are the v1.1 ship defaults).
- §8.2 'Cross-references' gains the §5.7 + §10 cross-
reference bullet, removing the trailing 'added by T3.1
itself' note (the bullet is now present and the list is
internally consistent).
scripts/apply_schemas.py / pipelines/_tests/test_papra_index_offline.py
are not touched (the schema freeze is preserved). The
PAPRA_INDEX_TABLE env var is read by the helper but is not
required by the backup / restore procedure; the Gitea
secrets for the new backup target bucket are the only new
env vars.
---ci---
project: inboxos
phase: 1
milestone: v1.1
status: execute
---/ci---
REQ-INB-15/19/20/21/23/25 all land new sections or
new artifacts in this v1.1 plan. The runbook §8.2 'Cross-
references' list gains three new bullets to keep it internally
consistent with the v1.1 deliverables:
- Papra write policy: extended to note the live-write gate
(REQ-INB-20) and the papra_index audit table (REQ-INB-19).
- Secret rotation (NEW): §6.4 (REQ-INB-21).
- Metrics surface (NEW): §4.5 (REQ-INB-23).
The §5.7 + §10 cross-reference for backups (REQ-INB-22) is
deliberately NOT added here; T3.1 inserts the §5.7 + §10
sections and adds the cross-reference bullet in the same PR so
the §8.2 list is always internally consistent. A trailing
paragraph notes this.
The existing bullets (Schemas, Extraction contract, Gitea
Actions, Pipelines, Papra write policy, Phase 1.1 verification)
remain in place. The Papra write policy bullet is extended (not
duplicated) to mention the new sub-sections.
No source code is modified; the entire change is documentation.
---ci---
project: inboxos
phase: 1
milestone: v1.1
status: execute
---/ci---
REQ-INB-24 closes the post-hoc-review backlog items P1-1 and P2-4
that the v1.0 close did not fit.
.ciagent/inboxos/plans/05-PLAN.md:
- The 'Parallelization plan (one PR per task)' table at
lines 318-330 gains a one-line footnote under the table:
'PR #C originally opened with 2 files; the third (papra-write-
policy.md §Rule 1 Live pipeline note:) was a follow-on added
in a hotfix during review. P1-1 was the absence of an explicit
three-file split in the plan; this footnote is the explicit
split.'
docs/operations-runbook.md:
- §9.2 row 19 (line 559 in pre-T1.2 numbering) gains a one-line
annotation in the 'Closed by' cell: '... owner: backend-
engineer (the P-7 papra_decide investigation; the asymmetry
is structural, the doc is the deliverable)'. The row now
explicitly names the persona.
.ciagent/inboxos/CI-LOG.md:
- P1-1 entry gains a 'closed_in: <T2.4 commit SHA>' pointer
pointing at the plans/05-PLAN.md footnote.
- P2-4 entry gains a 'closed_in: <T2.4 commit SHA>' pointer
pointing at the runbook §9.2 row 19 owner annotation.
- The 'remaining_for_phase_6' list loses both P1-1 and P2-4
(down to [P1-3, P1-5, P2-1, P2-2]). P1-3, P1-5, P2-1, P2-2
remain in the Phase 6 backlog (these are v1.1 candidate REQ-INB
IDs, closed by the v1.1 plan itself, not by T2.4).
CI-LOG.md is a CIAgent-side document and is not CPO-owned; the
lead-developer can edit it as part of this task. The exact
lines (96-97, 112-113, 115) are cited in the plan's must_haves.
No source code is modified; the entire change is documentation.
---ci---
project: inboxos
phase: 1
milestone: v1.1
status: execute
---/ci---
T1.7 closed the live-vs-historical Papra_Link asymmetry by adding
the parity PATCH in pipelines/live_pipeline.py. The §Rule 1
'Live pipeline note' paragraph (lines 70-81 in
docs/papra-write-policy.md) documented the asymmetry and is now
obsolete; remove it and replace with a single sentence pointing
at the post-T1.7 architecture:
'Both pipelines now capture Papra_Link on the NocoDB row
whenever the attachment walk returns a papra_link -- see
ARCHITECTURE.md §Document Store (curated) and the
papra_link_patched event in pipelines/live_pipeline.py.'
The preceding Rule 1 prose (lines 55-69) is unchanged. The
'Live-write gate' subsection added in T1.5 is unchanged. No
other papra-write-policy.md edit is needed; the cross-references
to docs/extraction-contract.md §Live vs historical and
ARCHITECTURE.md §Document Store still point to live docs.
---ci---
project: inboxos
phase: 1
milestone: v1.1
status: execute
---/ci---
T2.2 closes the call-site wiring for the T1.5 Papra live-write gate
and lands the per-run metrics.jsonl surface (REQ-INB-23). The
T1.5 + T2.2 work is folded into one commit so the two pipeline
files are touched by exactly one Wave 2 task.
pipelines/common.py:
- LLM_METRICS_ENABLED env-var gate around the
llm_call_seconds_sum / llm_call_count accumulators in
_ollama_call_one_model. The accumulators are stored in
os.environ so the main() functions can read them when emitting
the per-run metrics line. Default is 'true' (gate enabled).
pipelines/live_pipeline.py:
- Import emit_papra_write_gate_event and emit_metric.
- process_one_message: emit the papra_write_gate event at the
start of the papra branch (REQ-INB-20 call-site).
- main: emit one metrics line with the COUNTER_KEYS / GAUGE_KEYS
vocabulary from pipelines/_metrics/emit.py, including
llm_call_seconds_sum and llm_call_count read from the
os.environ accumulators.
pipelines/historical_pipeline.py:
- Import emit_papra_write_gate_event and emit_metric.
- process_one_message: emit the papra_write_gate event at the
start of the body-decision branch.
- main: emit one metrics line with the same vocabulary.
pipelines/_metrics/emit.py (new):
- emit_metric(run_id, pipeline, *, counters, gauges) appends one
JSONL line to <pipeline>-metrics-<run_id>.jsonl. The
COUNTER_KEYS and GAUGE_KEYS module constants pin the vocabulary
so the test can assert exact equality.
pipelines/_metrics/__init__.py (new):
- Empty / near-empty package marker.
pipelines/_tests/test_metrics_offline.py (new, 2 tests):
- test_emit_metric_creates_file_with_one_line_per_call: asserts
the line shape, the exact COUNTER_KEYS / GAUGE_KEYS, and the
per-run file naming.
- test_emit_metric_does_not_overwrite_existing_file: asserts two
calls in a row append, never truncate.
docs/operations-runbook.md:
- New §4.5 'Metrics surface' (after §4.4 'SeaweedFS bucket
layout' at line 238). Documents the file location, the counter
and gauge vocabulary, the tail-and-summarize procedure, the
opt-out via LLM_METRICS_ENABLED, and a forward-pointer noting
alerting is a v1.2 candidate (out of scope for v1.1).
---ci---
project: inboxos
phase: 1
milestone: v1.1
status: execute
---/ci---
REQ-INB-18 closes P1-3: the 'Per-table row counts at freeze' section
in docs/phase-1.1-verification/inb-28-report.md was empty (header
present, no actual counts). The section now has a 4-row table with
one row per module: finance, crm, intel, promotions. Each row
records rows_at_freeze (1 per module, the Phase 1.1 verification
freeze confirmed exactly one POST + one PATCH per module) and
first_post_at / first_patch_at timestamps mined from the synthetic
test's run history.
The papra_index table (REQ-INB-19, landed by T1.4) is documented
as having zero rows at the v1.0 freeze; row counts begin at the
v1.1 dispatch. The trailing paragraph is preserved with this
forward pointer.
The four pre-existing module tables (finance, crm, intel,
promotions) are unchanged; this is a documentation completion.
---ci---
project: inboxos
phase: 1
milestone: v1.1
status: execute
---/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---
REQ-INB-21 lands the secret-rotation helper and the runbook procedure.
scripts/rotate_secrets.sh (new, ~150 lines, set -euo pipefail):
- Accepts --dry-run (default) and --apply flags plus a positional
secret name.
- Reads the new value from STDIN (never a CLI arg) to avoid ps leaks.
- Calls pipelines.common.gitea_request via a python3 subshell to PUT
the new value to Gitea's actions-secrets endpoint. The Gitea
actions-secrets PUT is in-place (overwrites the existing secret
at the same name); the helper then verifies via GET that the
secret still exists under the new value.
- Exits 0 on success, 2 on missing env / missing value, 3 on Gitea
API failure, 4 on helper-internal error.
- Dry-run prints a redacted diff (sha256:8hex) of the new value
against an unknown placeholder for the old value (Gitea does
not return secret plaintexts via the API).
pipelines/_tests/test_rotate_secrets_offline.py (new, ~3 tests):
- test_dry_run_prints_diff_and_exits_zero_no_put
- test_apply_branch_runs_python_helper
- test_helper_fails_loud_when_env_unset
The 3 tests pass on the offline test host (the apply branch test
documents that exit code 0 or 3 is acceptable in this environment:
0 on a real Gitea, 3 on connection failure with no Gitea reachable).
docs/operations-runbook.md:
- §6.1 line 401 'future enhancement' parenthetical replaced with
'The helper landed in v1.1 (REQ-INB-21); see §6.4.'
- New §6.4 'Secret rotation' between §6.1 and §6.2: rotation
ordering (NOCODB_API_TOKEN -> SEAWEEDFS_* -> IMAP_PASSWORD ->
GITEA_USER/PASS), test-or-die gate, and a copy-paste invocation
example.
.env.example is not touched (env vars are unchanged; only the
helper and the procedure are new).
---ci---
project: inboxos
phase: 1
milestone: v1.1
status: execute
---/ci---
REQ-INB-20 introduces a Papra live-write engineering gate: a per-message
override that wins over the existing repo var, plus a canary procedure
and a structured papra_write_gate event that carries the effective
state.
pipelines/common.py:
- PapraConfig gains a dry_run_override: bool | None field parsed
from PAPRA_DRY_RUN_OVERRIDE (true/1/yes/on -> True; false/0/no/off
-> False; empty string -> None). The effective dry_run is
dry_run_override if not None else <existing logic at the repo
var PAPRA_DRY_RUN>.
- New emit_papra_write_gate_event(cfg, logger) helper (after the
PapraConfig block). Emits a single papra_write_gate event with
the three documented fields (dry_run, dry_run_override,
papra_dry_run_env). No side effects.
pipelines/_tests/test_papra_decide_offline.py:
- _default_cfg now sets dry_run_override=None.
- test_papra_config_unconfigured_when_env_empty also clears
PAPRA_DRY_RUN_OVERRIDE and asserts dry_run_override is None.
- New test_papra_dry_run_override_wins: three cases pinning the
precedence (override=true beats repo=false; override=false
beats repo=true; empty override -> repo wins, override is None).
- New test_emit_papra_write_gate_event_logs_three_fields: asserts
the helper emits exactly one papra_write_gate event with the
three documented fields.
docs/papra-write-policy.md:
- New 'Live-write gate' subsection after 'Flipping the dry-run
switch' (line 134). Documents the override precedence table,
the canary procedure (max_emails=1, 10, 100), and the test
coverage.
- The §'Flipping the dry-run switch' subsection is unchanged.
The T1.5 helper is callable but uncalled at the end of this commit;
the call-sites in live_pipeline.py and historical_pipeline.py are
landed in T2.2 alongside the metrics call-sites so the two pipeline
files are touched by exactly one Wave 2 task.
---ci---
project: inboxos
phase: 1
milestone: v1.1
status: execute
---/ci---
REQ-INB-19 introduces a new NocoDB table, papra_index, as the per-message
audit trail for every Papra write intent. The four pre-existing
module tables (finance, crm, intel, promotions) are unchanged from
the Phase 1.1 freeze; only the new table is added.
docs/schemas.md gains a new top-level section after the promotions
table with the 7 columns and their types/constraints. The
'Schema changes (process)' procedure applies; apply_schemas.py
will be amended in the next commit to register the new table.
docs/phase-1.1-verification/inb-28-report.md (the Phase 1.1 freeze
record) gains a paragraph noting the new table's status (planned
in v1.1; created by apply_schemas.py on first re-run; zero rows at
the v1.0 freeze) and a forward pointer to the Phase 1.1 row-count
check (REQ-INB-18, T2.1).
---ci---
project: inboxos
phase: 1
milestone: v1.1
status: execute
---/ci---
The table has 22 data rows: 6 IMAP + 4 SeaweedFS + 4 NocoDB + 2 Ollama + 3 Papra + 3 Gitea (INSTANCE_URL, USER, PASS). The v1.0 ship counted 21 because GITEA_USER / GITEA_PASS was treated as one credential. Replace the stale count and the stale rationale with the corrected count, the rationale (GITEA_USER / GITEA_PASS row was treated as one credential), and a corrected rounding note that pins the source of the '15' to the Papra trio being optional.
---ci---
project: inboxos
phase: 1
milestone: v1.1
status: execute
---/ci---
The previous glob cited upload-artifact@v3 across {live,historical,ci-pr}.yml. Verification: 'grep -n upload-artifact .gitea/workflows/ci-pr.yml' returns zero hits. The pin is real only in live-pipeline.yml:150 and historical-pipeline.yml:170. Replace the misleading glob with the two concrete line citations and a parenthetical noting that ci-pr.yml has no upload-artifact step.
The §'v3 pinning' paragraph in docs/gitea-actions.md:247 already correctly scopes the v3 pin to live + historical only; no edit required.
---ci---
project: inboxos
phase: 1
milestone: v1.1
status: execute
---/ci---
Board mandate INB-123 establishes the CPO as sole author. CEO drafted the seed template on the CPOs behalf. CPO will author the first real content under INB-124 and INB-125.
- P1-4: Redraw runbook §1 system diagram to remove the OpenCode CLI
node (the runner now calls Ollama's /v1/chat/completions directly).
- P1-6: Fix CI-LOG.md ED-1 effect: value to be a single-line string
(was multi-line continuation that YAML interprets as nested keys).
- P1-2: Update plan §Phase 5 acceptance gate row 16 to use §6.1
reference (was :487; the runbook grew 13 lines during Wave 1+2).
- Update plan row 19 to reflect the ED-1 no-op (live papra_decide
at line 490 is already the post-classify call).
Remaining P1/P2 issues are filed in the COMPLETE commit's
post-hoc-review block as Phase 6 backlog.
---ci---
project: inboxos
phase: 5
milestone: v1.0
status: review
refs_review_issues: [P1-2, P1-4, P1-6]
files: [docs/operations-runbook.md, .ciagent/inboxos/CI-LOG.md, .ciagent/inboxos/plans/05-PLAN.md]
---/ci---
The runbook's state-file inventory drifted from the actual code.
Field names now match pipelines/live_pipeline.py:600-603 and
pipelines/historical_pipeline.py:516-521.
---ci---
project: inboxos
phase: 5
milestone: v1.0
status: execute
pr: H
task: T2.1
persona: devops-engineer
ref: P-6
refs_requirements: [REQ-INB-3, REQ-INB-6]
files: [docs/operations-runbook.md]
---/ci---
The inb-28-report was referenced by docs/operations-runbook.md §4.3
and §8.2 but the file did not exist. Reconstructing from
docs/schemas.md (column spec) and
pipelines/_tests/test_upsert_synthetic.py (table IDs) per the
test's TABLES dict.
---ci---
project: inboxos
phase: 5
milestone: v1.0
status: execute
pr: G
task: T1.7
persona: data-engineer
ref: missing-artifact
refs_requirements: [REQ-INB-5, REQ-INB-13]
files: [docs/phase-1.1-verification/inb-28-report.md]
---/ci---
coreci-coo
saa
cto-ciagent
CTO
cloudinit-bot