@spec accepted_types(
  StatifierBlocks.Document.t(),
  StatifierBlocks.Palette.t(),
  {StatifierBlocks.Block.id(), StatifierBlocks.Block.slot_name()},
  StatifierBlocks.Assignability.context()
) :: MapSet.t(StatifierBlocks.Block.type_name())

Which of palette's block types would be accepted at target.

target is a {parent_id, slot} pair, the granularity droppable_slots_for/4 answers at; the index within the slot is not part of the question, for the reason the moduledoc's reduction gives.

This is the palette's own filter - what "+" offers here, and what an insert picker offers there - and it is droppable_slots_for/4's predicate asked once per candidate type against a probe block of that type. Not a parallel implementation: the same function, with a block that is not in the document yet, which is exactly the case droppable_slots_for/4 exists to serve.

The probe is probe/2's, which is the part a surface writing this filter by hand gets wrong: a type whose StatifierBlocks.BlockType.palette_entry/0 declares a default_config affecting what it reads is answered differently by a probe built from StatifierBlocks.Palette.new_block/2 alone. Two views filtering the same palette against the same document then disagree about whether a type fits, and neither is visibly wrong.

A type that does not resolve through palette is left out rather than raising, the way every other palette walk in this package treats one.

@spec droppable_slots(
  StatifierBlocks.Document.t(),
  StatifierBlocks.Palette.t(),
  StatifierBlocks.Block.id(),
  StatifierBlocks.Assignability.context()
) :: [{StatifierBlocks.Block.id(), StatifierBlocks.Block.slot_name()}]

Slots that would accept id's block: declared, kind-admitted (rule 1 and the index-free half of rule 2), with room (rule 3), and outside the block's own subtree (rule 4). Per-slot, not per-gap - see the moduledoc for the reduction this projects from.

id naming no block in document yields []: there is no block to drag, so there is nothing to ask droppable_slots_for/3 about.

@spec droppable_slots_for(
  StatifierBlocks.Document.t(),
  StatifierBlocks.Palette.t(),
  StatifierBlocks.Block.t(),
  StatifierBlocks.Assignability.context()
) :: [{StatifierBlocks.Block.id(), StatifierBlocks.Block.slot_name()}]

The same predicate as droppable_slots/3, taking a %Block{} directly so a block not yet in document - the palette's "+" button, ADR-0005 decision 8 - can be asked the same question. droppable_slots/3 is a lookup followed by a call to this function.

@spec probe(StatifierBlocks.Palette.t(), StatifierBlocks.Block.type_name()) ::
  {:ok, StatifierBlocks.Block.t()} | :error

A block of type as the assignability questions should be asked about it.

StatifierBlocks.Palette.new_block/2's block, with the type's StatifierBlocks.BlockType.palette_entry/0 default_config merged over its config. Without the merge, a block type whose read is declared on a config field - a path field, say - declares no read at all while that field holds its schema default, and every slot stamps ok: the drop-time refusal ADR-0011 promises never fires for exactly the blocks whose reads are worth checking. default_config is the entry saying what the author is about to configure, so the probe asks the question the configured block would ask.

This is the probe only. The block a pick or a drop actually inserts still comes from StatifierBlocks.Palette.new_block/2: the entry's declaration is what a type would be asked about, not a config the author never wrote.

palette_entry/0 is optional and a type name can resolve to a module that is not loadable, so both are checked the way StatifierBlocks.Environment.subject_path/2 checks them for the same callback.

@spec slot_verdicts(
  StatifierBlocks.Document.t(),
  StatifierBlocks.Palette.t(),
  StatifierBlocks.Block.t(),
  StatifierBlocks.Assignability.context()
) :: [
  {{StatifierBlocks.Block.id(), StatifierBlocks.Block.slot_name()},
   slot_verdict()}
]

Every slot this module considers, with its verdict for block - the accepting ones and the refusing ones, in one pass.

droppable_slots_for/3 keeps the :ok rows of this list, so the accepting set and the reasons for the refusing set come from one enumeration and one decision. The rows are StatifierBlocks.Assignability.target_verdicts/4's positions projected to slots, first-appearance order preserved, with rules 3 and 4 applied after the projection exactly as before.

What a refused slot's reason is, and when there is none

A slot is refused when every gap in it was refused - that is the existential reduction the moduledoc argues for, read the other way round. So a slot-level reason exists only when the gaps agree:

• each gap's reason is Assignability.finding_reason/2 of its first finding, in the order Assignability.check/5 documents - so a gap that fails kind admission reports nil, because that gate's finding names both kind sets itself and is the more interesting of the two things wrong with such a gap;
• the slot's reason is that value when every gap gave the same non-nil one, and nil otherwise.

nil is therefore honest rather than lossy: it says this slot has no one data-flow reason to show the author - because the refusal was structural (:kind_not_admitted names both kind sets itself), because it was rule 3 or rule 4 (no room, or the block's own subtree, neither of which is an assignability question at all), or because different gaps refused differently and picking one of them would be picking arbitrarily.

Only the two refusing arms of the vocabulary can ever appear here. The three untyped arms sit on seams that were admitted, and an admitted gap makes its whole slot :ok - which is the amendment's "the reason explains, it never refuses more" holding at this layer too, by construction rather than by discipline.

Which refusing arm reaches slot level depends on which seam refused, and this is worth saying rather than leaving to be discovered. Through a slot's insertion seams only :not_assignable can: {:fixable_by, block_id} needs every gap in a slot to name the same producing block, and a slot's gaps name different ones by construction - gap 0's producing side is the slot's own inbound (:slot_entry) and gap i's is the sibling at i - 1 - so a slot with more than one gap refusing at all of them disagrees with itself and reports nil. Through the vacated seam (Assignability.check/5's third seam, present only for a move) {:fixable_by, _} is reachable and expected: a move that would break the seam it leaves behind yields the same :type_mismatch at every position in the document, naming the block before the candidate's current position, so every otherwise-accepting gap agrees and every such slot reads {:refused, {:fixable_by, id}} - including slots elsewhere in the tree, whose reason then names a seam in the source slot. A gap that also refuses on its own insertion seam takes that seam's reason instead (insertion seams precede the vacated seam in check/5's order). The finding still carries the position-level answer in every case, and the per-slot attribute does not pretend to an answer the granularity cannot support.