I2966 — A forge setting that could not be read is unknown, never \"allows nothing\"
Read the repository's merge settings as unknown when the forge's answer does not carry them, and say so in the integration policy, in each held pull request's reason and evidence and in the queue's diagnostics, instead of reporting that the repository allows no merge commit.
DONE wave 0 · p0 · implementation profile · parallel safe
Part of development-runtime — The runtime has a development surface.
Objective
Read the repository's merge settings as unknown when the forge's answer does not carry them, and say so in the integration policy, in each held pull request's reason and evidence and in the queue's diagnostics, instead of reporting that the repository allows no merge commit.
Why
Truth sweep 2026-10-18 (f6, S1, verified): the published https://majordomus.dev/cockpit/integration/ and /cockpit/trains/ said 'korczis/prismatic-majordomus allows no merge commit (it allows: nothing): the executor never squashes or rebases, so no pull request can be ready', holding every pull request as merge_commit_not_allowed, while `gh api repos/korczis/prismatic-majordomus` answers allow_merge_commit, allow_squash_merge and allow_rebase_merge all true. integration/forge.rs read each setting with `.and_then(Value::as_bool).unwrap_or(false)`, so a token that may not read them (the Pages workflow's) turned an absent setting into a refusal. This is the alpha-visible instance of 3e's class I2846 (unknown is never healthy).
Current state
Fixed in this change: ForgeObservation.merge_methods is None when the answer carries none of the three settings; IntegrationPolicy.merge_settings_unread is set from it; a held pull request reads merge_settings_unread with disposition unknown and repository_settings evidence saying the settings could not be read; the diagnostic names the unread settings and never says 'allows nothing'.
Desired state
An unread merge setting is unknown on every surface that shows the queue; a read `false` still holds as merge_commit_not_allowed; recorded observations that carry the array read as before.
Scope
- apps/majordomus-cli/src/integration/forge.rs
- apps/majordomus-cli/src/integration/mod.rs
- apps/majordomus-cli/src/integration/classify.rs
- apps/majordomus-cli/src/integration/model.rs
- apps/majordomus-cli/src/integration/tests.rs
- apps/majordomus-cli/src/integration/train.rs
- apps/majordomus-cli/src/integration/drain.rs
- apps/majordomus-cli/src/capability/builtin/brief.rs
- apps/majordomus-cli/src/capability/builtin/integration.rs
- apps/majordomus-cli/src/cockpit/pages.rs
- apps/majordomus-cli/src/commands/prs.rs
- docs/INTEGRATION.md
Dependencies
None. This issue is a root of the graph.
Acceptance criteria
- A forge answer without the merge settings yields no merge methods (unknown), and one with them yields what they allow
- A pull request held for unread settings reads merge_settings_unread with disposition unknown, and nothing merges
- The queue's diagnostic says the merge settings could not be read and never that the repository allows nothing
Validation
- majordomus plan validate
Evidence required
- unread_merge_settings_are_unknown_and_never_allow_nothing
Evidence
| covers | type | command | result | at commit |
|---|---|---|---|---|
| unread_merge_settings_are_unknown_and_never_allow_nothing | ci | cargo test --lib -- integration::tests::unread_merge_settings_are_unknown_and_never_allow_nothing integration::forge::tests::merge_settings_absent_from_the_answer_are_unread_and_present_ones_are_read | both ok in validate run 39192952944, job rust (2) 117890228077 (3482 passed, 0 failed), every job green at master dd4c0a87cba, which contains the fix 269bf5d67c3 | 9a5a9b7 |
Timeline
- started
- 2026-10-20T15:44:19Z
- verified
- —
- completed
- 2026-10-20T15:44:54Z
Those three fields, the evidence above and the state of the dependencies are all the status is made of. There is no status field to disagree with them.
Canonical record: .ai/repo/project/issues/I2966.yaml. Read it back with majordomus plan show I2966.