Can we call this guide "Adding form logic" or something like that, and then say "signal forms allows you to add logic to your form using schemas" and just refer to it as "schemas" from the on instead of "schema field configuration"

This sounds like its saying that schemas are for logic other than validation, and you specify validation some other way. I think we could make it more clear by saying that validation logic is covered in [link] and this guide discusses other rules available in schemas

Ah I see where the "configuration" stuff is coming from now. We call these rules, e.g. "thedisabled rule". I think a clearer way to say this is "Rules bind reactive logic to specific fields in your form. Most rules accept a reactive logic function as an optional argument. The reactive logic function automatically recomputes whenever the signals it references change, just like acomputed"

Maybe we could try to diagram out the anatomy or something:

disabled(schemaPath.couponCode, ({valueOf}) => valueOf(schemaPath.total) < 50);~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~rule     path                   reactive logic function

Shouldn't this new'new' be on the'Schema field configuration' object?

nit:

Nit: I would expect the auto-formatting to add those.

Edit: Oh okay, it doesn't because prettier don't understandangular-ts.
Anyway, it's just a nit.
It would be worth asking if prettier could support the angular syntax code block. I openedprettier/prettier#18500 for this.

This section is inaccurate. From thedurationOrDebouncer parameter documentation:

TheDebouncer function isn't a reactive logic function. It's just a callback that is called every time the control value is updated. It's expected to return nothing (undefined) to immediately synchronize the update, or a promise that will prevent synchronization until it resolves.

For example, thedebounce() rule converts the duration to such a function:

"configure HTML attributes" is overly specific and already done automatically for the built-in ones. I think it's sufficient to just saymetadata() provides a way to publish some additional data associated with a field.

IIRC@mmalerba had a good example for labels?

This won't compile. The type checker prevents the user from explicitly binding any of the built-in attributes when the[field] directive is present, because it'll automatically bind these for you.

I don't think we want to encourage setting built-in metadata this way.min(schemaPath.score, 0) is preferable in this case.

@mmalerba correct me if I'm wrong, but this isn't the purpose of the "managed" key. All metadata keys support reducers for accumulating values if desired. The "managed" variant is for data that wants to compute a new valuefrom the accumulated/reduced value.

Great example for a custom metadata key, but sinceMAX is built-in, there's already a signal that exposes it directly:

value.set won't work here sincevalue is a computed which are readonly.

I'd just go through the field here:

[value]="field().value()"(input)="field().value.set(...)"

Again, since these three metadata are built-in, you can just use the built-in properties to access them: