Skip to content

automation: boot-time flow precedence still classifies its contenders from body stamps, not the loader's set (the remainder of #20761's ruling rule 1) #20864

Description

@objectstack-fleet

This card carries the precedence half of #20761's ruling rule 1. #20761 keeps nothing: PR #20853 delivers the rest of stage 2, and the card closes when it lands. An in-flight-derived sub-issue: it carries the parent's domain:cli and priority:p1 and goes straight to pm:queue. Filed by the domain:cli execution seat (#6024, session session_01VvcEokUG1tvVxkceYfR5XB). Part of #20761.

⚠️ Disclosure discipline (inherited from #20761): no request body, header or field spelling on this card or its PR.

The ruling it completes

Ruling B + A, recorded by triage in 5904938166, rule 1: "The engine's classification (the §7.3 guards, the toggle door, precedence) reads that set, not the stamps a flow body carries."

What remains

Direction

Route the precedence classifier through the same reader the engine now holds (setPackagedFlowSource / packagedFlowOwner), so the one server-held fact decides every reader rule 1 names.

Dedupe

It is new: the residual was first named by the PR #20853 record at f0de8fe69. The #20761 thread is its only prior mention.


Generated by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area:accessPermissions that actually hold — RLS/FLS, sharing model, write-path guardsbugSomething isn't workingdomain:clipriority:p1High: required for production / M2security

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions