💥 Fail fast on function-component failures, collect explicitly by taras · Pull Request #251 · taras/executable.md

taras · 2026-07-31T13:31:06Z

Why

Function-component failures were collected into ErrorSegments by default, with fatality an opt-in carried by an internal abort marker. That is inverted: a component that fails now fails the operation it is part of, like any other Effection work, and continuing is an explicit scope-local choice.

Closes#249.

What changes

Default. An ordinary failure propagates after the invocation has been dismantled — projected content, then the component's own resources, then retained work. An Error propagates by identity with its type and cause; a non-Error becomes an Error carrying the original value as cause; body-plus-teardown propagates as the complete aggregate withInvocation() produced. Later siblings do not run.

Component.handleFailure(failure) is the one contextual seam. The default fails the operation. It is called only for an ordinary invocation failure and only after complete teardown. Durability failures, an already-selected DocumentationError, the content transport, and schema diagnostics are classified before it and never reach it.

Two collection forms, one middleware.collectFailures(fn) marks a component by exact function identity and returns the same object. <CollectFailures> is reserved engine syntax that expands its content in the caller's frame, preserving structured segments. Both install the same terminal middleware, so the nearest boundary handles a failure once.

Collection converts a failure into one diagnostic whose cause is the complete original, and does not change the ambient policy — under documentation a collected failure still stops the document.

How it works

The boundary is installed outside the whole withInvocation() call, and scoped:

scoped:
useFailureCollection() ← still installed during teardown
withInvocation:
definition.fn(props)
ordered teardown ← a failure here is still inside the boundary
catch → classify → handleFailure()

Outside, because middleware a component installs for itself is gone before its own teardown can fail. Scoped, because a component that collects its own failures must not quietly decide that for its siblings.

Removed

abortOrdinaryComponentFailures, abortsOrdinaryComponentFailures, the function-identity abort weak set, componentAbort, its error weak set, the aborted arm of fatalCause, hasOrdinaryFailure with its traversal, the agent fatally() wrappers, and the AgentProvider decoration. Agent components now simply throw; they stay fail-fast because that is the default.

Kept and updated: withInvocation(), InvocationTeardownError, durability precedence, AmbientErrorPolicy/settle()/DocumentationError, Component.raise and exactly-once observation, cause attribution, ContentError/tryContent()/the content transport.

What this changed for existing components

Core's <File>, <Glob>, <Parse>, <SafeParse> and <TempDir> have documented diagnostic-and-continue behavior — 44 tests assert it — so they are marked collectFailures(...). That is the decorator's purpose, and it preserves their behavior exactly rather than changing it in a refactor.

Test fixtures whose point is observing a diagnostic are likewise marked; fixtures asserting engine defaults were updated to the new semantics.

How to verify it

Tier CF (tests/failure-collection.test.ts), 11 cases covering the issue's matrix. Every one distinguishes a failed operation from a completed one containing a diagnostic — output text alone cannot tell those apart:

CF1–CF4: unmarked failure by identity with nothing after it; teardown-only; body-plus-teardown aggregate; non-Error normalization with the exact value in cause.
CF5–CF7: collectFailures reports once and continues; the marker is identity, not name; it collects a teardown-only failure.
CF8–CF11: <CollectFailures> handles a direct child and continues; reaches a nested component's failure and handles it once; does not collect durability; under a throwing policy reports once and still stops.

FC5/FC5b pin both halves end-to-end through execute(): an unmarked repository component fails the execution with nothing rendered, and the same component marked reports and continues.

Gate on Deno 2.9.1: fmt / lint / check / test (272 passed, 0 failed) / check:jsr, pnpm exec tsc --project tsconfig.node.json --noEmit, deno task build && ./dist/xmd test packages/core/src --raw (exit 0, 0 failures), git diff --check.

Scope

Per the issue: no WebForm, no Elicit, no remaining #202 migrations, and the TD8 daemon-liveness defect (#248) is deliberately not fixed here.

#247 stays open and will be rebased on this.

An ordinary failure now fails the operation it is part of, after the invocation has been dismantled. Continuing is a scope-local choice: collectFailures(fn) for a component, <CollectFailures> for a region. Closes#249.

github-actions

Found 5 redundant comments. Inline suggestions to remove them below.

github-actions · 2026-07-31T13:31:48Z

+ // deno-lint-ignore require-yield
+ *handleFailure(failure: ComponentFailure): Operation<ErrorSegment> {
+ // The default is to fail, so a component that goes wrong stops the work it
+ // was part of rather than quietly becoming a note in the output.


Redundant comment — restates what the code does.
Suggested change
// was part of rather than quietly becoming a note in the output.

github-actions · 2026-07-31T13:31:48Z

+ /** The invocation itself, and what a failure of it means. */
+ const invoke = function* (): Operation<Segment[]> {
+ // Detached and frozen: what a component reads about its call site is a copy,
+ // so nothing it does can reach the element the parser built.


Redundant comment — restates what the code does.
Suggested change
// so nothing it does can reach the element the parser built.

github-actions · 2026-07-31T13:31:48Z

+ const outcome = yield* handle.tryProject({ kind: "slot", name: slotName });
+ // A documentation failure is presented in the public shape, as
+ // `content()` does, so a component recovering from one sees the
+ // same thing either way.


Redundant comment — restates what the code does.
Suggested change
// same thing either way.

github-actions · 2026-07-31T13:31:48Z

+// teardown together.
+
+// Not the document's failure to render: a journal that no longer describes
+// this run, or a policy that has already decided the document fails.


Redundant comment — restates what the code does.
Suggested change
// this run, or a policy that has already decided the document fails.

github-actions · 2026-07-31T13:31:48Z

 ): FunctionComponentDefinition {
- return { kind: "function", name, props: NO_PROPS, fn: body };
+ // These fixtures exist to be observed failing, so they collect rather than
+ // stopping the expansion the assertion is about.


Redundant comment — restates what the code does.
Suggested change
// stopping the expansion the assertion is about.

github-actions · 2026-07-31T13:32:01Z

PR #251: 💥 Fail fast on function-component failures, collect explicitly

22 files, +737 / -463

Scope

🔴 PR has 1200 lines changed. Split into focused PRs.

🟡 1200 lines changed. PRs under 400 receive more thorough review.

🟡 22 files changed. Are all changes related?

Structural

🟡 Type declarations with no consumers: FatalFailure.

Symbol	Declared at	Refs in diff	Why flagged
`FatalFailure`	`packages/core/src/errors.ts:131`	1	referenced ≤1× within the added diff (pre-existing usages not counted)

Slop

✅ Slop indicators look low.

Static Analysis

✅ Oxlint found no issues.

Correctness

No extraneous code patterns detected.

taras · 2026-07-31T13:31:06Z

Why

Function-component failures were collected into ErrorSegments by default, with fatality an opt-in carried by an internal abort marker. That is inverted: a component that fails now fails the operation it is part of, like any other Effection work, and continuing is an explicit scope-local choice.

Closes#249.

What changes

Default. An ordinary failure propagates after the invocation has been dismantled — projected content, then the component's own resources, then retained work. An Error propagates by identity with its type and cause; a non-Error becomes an Error carrying the original value as cause; body-plus-teardown propagates as the complete aggregate withInvocation() produced. Later siblings do not run.

Component.handleFailure(failure) is the one contextual seam. The default fails the operation. It is called only for an ordinary invocation failure and only after complete teardown. Durability failures, an already-selected DocumentationError, the content transport, and schema diagnostics are classified before it and never reach it.

Two collection forms, one middleware.collectFailures(fn) marks a component by exact function identity and returns the same object. <CollectFailures> is reserved engine syntax that expands its content in the caller's frame, preserving structured segments. Both install the same terminal middleware, so the nearest boundary handles a failure once.

Collection converts a failure into one diagnostic whose cause is the complete original, and does not change the ambient policy — under documentation a collected failure still stops the document.

How it works

The boundary is installed outside the whole withInvocation() call, and scoped:

scoped:
useFailureCollection() ← still installed during teardown
withInvocation:
definition.fn(props)
ordered teardown ← a failure here is still inside the boundary
catch → classify → handleFailure()

Outside, because middleware a component installs for itself is gone before its own teardown can fail. Scoped, because a component that collects its own failures must not quietly decide that for its siblings.

Removed

abortOrdinaryComponentFailures, abortsOrdinaryComponentFailures, the function-identity abort weak set, componentAbort, its error weak set, the aborted arm of fatalCause, hasOrdinaryFailure with its traversal, the agent fatally() wrappers, and the AgentProvider decoration. Agent components now simply throw; they stay fail-fast because that is the default.

Kept and updated: withInvocation(), InvocationTeardownError, durability precedence, AmbientErrorPolicy/settle()/DocumentationError, Component.raise and exactly-once observation, cause attribution, ContentError/tryContent()/the content transport.

What this changed for existing components

Core's <File>, <Glob>, <Parse>, <SafeParse> and <TempDir> have documented diagnostic-and-continue behavior — 44 tests assert it — so they are marked collectFailures(...). That is the decorator's purpose, and it preserves their behavior exactly rather than changing it in a refactor.

Test fixtures whose point is observing a diagnostic are likewise marked; fixtures asserting engine defaults were updated to the new semantics.

How to verify it

Tier CF (tests/failure-collection.test.ts), 11 cases covering the issue's matrix. Every one distinguishes a failed operation from a completed one containing a diagnostic — output text alone cannot tell those apart:

CF1–CF4: unmarked failure by identity with nothing after it; teardown-only; body-plus-teardown aggregate; non-Error normalization with the exact value in cause.
CF5–CF7: collectFailures reports once and continues; the marker is identity, not name; it collects a teardown-only failure.
CF8–CF11: <CollectFailures> handles a direct child and continues; reaches a nested component's failure and handles it once; does not collect durability; under a throwing policy reports once and still stops.

FC5/FC5b pin both halves end-to-end through execute(): an unmarked repository component fails the execution with nothing rendered, and the same component marked reports and continues.

Gate on Deno 2.9.1: fmt / lint / check / test (272 passed, 0 failed) / check:jsr, pnpm exec tsc --project tsconfig.node.json --noEmit, deno task build && ./dist/xmd test packages/core/src --raw (exit 0, 0 failures), git diff --check.

Scope

Per the issue: no WebForm, no Elicit, no remaining #202 migrations, and the TD8 daemon-liveness defect (#248) is deliberately not fixed here.

#247 stays open and will be rebased on this.

An ordinary failure now fails the operation it is part of, after the invocation has been dismantled. Continuing is a scope-local choice: collectFailures(fn) for a component, <CollectFailures> for a region. Closes#249.

github-actions

Found 5 redundant comments. Inline suggestions to remove them below.

github-actions · 2026-07-31T13:31:48Z

+ // deno-lint-ignore require-yield
+ *handleFailure(failure: ComponentFailure): Operation<ErrorSegment> {
+ // The default is to fail, so a component that goes wrong stops the work it
+ // was part of rather than quietly becoming a note in the output.


Redundant comment — restates what the code does.
Suggested change
// was part of rather than quietly becoming a note in the output.

github-actions · 2026-07-31T13:31:48Z

+ /** The invocation itself, and what a failure of it means. */
+ const invoke = function* (): Operation<Segment[]> {
+ // Detached and frozen: what a component reads about its call site is a copy,
+ // so nothing it does can reach the element the parser built.


Redundant comment — restates what the code does.
Suggested change
// so nothing it does can reach the element the parser built.

github-actions · 2026-07-31T13:31:48Z

+ const outcome = yield* handle.tryProject({ kind: "slot", name: slotName });
+ // A documentation failure is presented in the public shape, as
+ // `content()` does, so a component recovering from one sees the
+ // same thing either way.


Redundant comment — restates what the code does.
Suggested change
// same thing either way.

github-actions · 2026-07-31T13:31:48Z

+// teardown together.
+
+// Not the document's failure to render: a journal that no longer describes
+// this run, or a policy that has already decided the document fails.


Redundant comment — restates what the code does.
Suggested change
// this run, or a policy that has already decided the document fails.

github-actions · 2026-07-31T13:31:48Z

 ): FunctionComponentDefinition {
- return { kind: "function", name, props: NO_PROPS, fn: body };
+ // These fixtures exist to be observed failing, so they collect rather than
+ // stopping the expansion the assertion is about.


Redundant comment — restates what the code does.
Suggested change
// stopping the expansion the assertion is about.

github-actions · 2026-07-31T13:32:01Z

PR #251: 💥 Fail fast on function-component failures, collect explicitly

22 files, +737 / -463

Scope

🔴 PR has 1200 lines changed. Split into focused PRs.

🟡 1200 lines changed. PRs under 400 receive more thorough review.

🟡 22 files changed. Are all changes related?

Structural

🟡 Type declarations with no consumers: FatalFailure.

Symbol	Declared at	Refs in diff	Why flagged
`FatalFailure`	`packages/core/src/errors.ts:131`	1	referenced ≤1× within the added diff (pre-existing usages not counted)

Slop

✅ Slop indicators look low.

Static Analysis

✅ Oxlint found no issues.

Correctness

No extraneous code patterns detected.

taras · 2026-07-31T13:31:06Z

Why

Function-component failures were collected into ErrorSegments by default, with fatality an opt-in carried by an internal abort marker. That is inverted: a component that fails now fails the operation it is part of, like any other Effection work, and continuing is an explicit scope-local choice.

Closes#249.

What changes

Default. An ordinary failure propagates after the invocation has been dismantled — projected content, then the component's own resources, then retained work. An Error propagates by identity with its type and cause; a non-Error becomes an Error carrying the original value as cause; body-plus-teardown propagates as the complete aggregate withInvocation() produced. Later siblings do not run.

Component.handleFailure(failure) is the one contextual seam. The default fails the operation. It is called only for an ordinary invocation failure and only after complete teardown. Durability failures, an already-selected DocumentationError, the content transport, and schema diagnostics are classified before it and never reach it.

Two collection forms, one middleware.collectFailures(fn) marks a component by exact function identity and returns the same object. <CollectFailures> is reserved engine syntax that expands its content in the caller's frame, preserving structured segments. Both install the same terminal middleware, so the nearest boundary handles a failure once.

Collection converts a failure into one diagnostic whose cause is the complete original, and does not change the ambient policy — under documentation a collected failure still stops the document.

How it works

The boundary is installed outside the whole withInvocation() call, and scoped:

scoped:
useFailureCollection() ← still installed during teardown
withInvocation:
definition.fn(props)
ordered teardown ← a failure here is still inside the boundary
catch → classify → handleFailure()

Outside, because middleware a component installs for itself is gone before its own teardown can fail. Scoped, because a component that collects its own failures must not quietly decide that for its siblings.

Removed

abortOrdinaryComponentFailures, abortsOrdinaryComponentFailures, the function-identity abort weak set, componentAbort, its error weak set, the aborted arm of fatalCause, hasOrdinaryFailure with its traversal, the agent fatally() wrappers, and the AgentProvider decoration. Agent components now simply throw; they stay fail-fast because that is the default.

Kept and updated: withInvocation(), InvocationTeardownError, durability precedence, AmbientErrorPolicy/settle()/DocumentationError, Component.raise and exactly-once observation, cause attribution, ContentError/tryContent()/the content transport.

What this changed for existing components

Core's <File>, <Glob>, <Parse>, <SafeParse> and <TempDir> have documented diagnostic-and-continue behavior — 44 tests assert it — so they are marked collectFailures(...). That is the decorator's purpose, and it preserves their behavior exactly rather than changing it in a refactor.

Test fixtures whose point is observing a diagnostic are likewise marked; fixtures asserting engine defaults were updated to the new semantics.

How to verify it

Tier CF (tests/failure-collection.test.ts), 11 cases covering the issue's matrix. Every one distinguishes a failed operation from a completed one containing a diagnostic — output text alone cannot tell those apart:

CF1–CF4: unmarked failure by identity with nothing after it; teardown-only; body-plus-teardown aggregate; non-Error normalization with the exact value in cause.
CF5–CF7: collectFailures reports once and continues; the marker is identity, not name; it collects a teardown-only failure.
CF8–CF11: <CollectFailures> handles a direct child and continues; reaches a nested component's failure and handles it once; does not collect durability; under a throwing policy reports once and still stops.

FC5/FC5b pin both halves end-to-end through execute(): an unmarked repository component fails the execution with nothing rendered, and the same component marked reports and continues.

Gate on Deno 2.9.1: fmt / lint / check / test (272 passed, 0 failed) / check:jsr, pnpm exec tsc --project tsconfig.node.json --noEmit, deno task build && ./dist/xmd test packages/core/src --raw (exit 0, 0 failures), git diff --check.

Scope

Per the issue: no WebForm, no Elicit, no remaining #202 migrations, and the TD8 daemon-liveness defect (#248) is deliberately not fixed here.

#247 stays open and will be rebased on this.

An ordinary failure now fails the operation it is part of, after the invocation has been dismantled. Continuing is a scope-local choice: collectFailures(fn) for a component, <CollectFailures> for a region. Closes#249.

github-actions

Found 5 redundant comments. Inline suggestions to remove them below.

github-actions · 2026-07-31T13:31:48Z

+ // deno-lint-ignore require-yield
+ *handleFailure(failure: ComponentFailure): Operation<ErrorSegment> {
+ // The default is to fail, so a component that goes wrong stops the work it
+ // was part of rather than quietly becoming a note in the output.


Redundant comment — restates what the code does.
Suggested change
// was part of rather than quietly becoming a note in the output.

github-actions · 2026-07-31T13:31:48Z

+ /** The invocation itself, and what a failure of it means. */
+ const invoke = function* (): Operation<Segment[]> {
+ // Detached and frozen: what a component reads about its call site is a copy,
+ // so nothing it does can reach the element the parser built.


Redundant comment — restates what the code does.
Suggested change
// so nothing it does can reach the element the parser built.

github-actions · 2026-07-31T13:31:48Z

+ const outcome = yield* handle.tryProject({ kind: "slot", name: slotName });
+ // A documentation failure is presented in the public shape, as
+ // `content()` does, so a component recovering from one sees the
+ // same thing either way.


Redundant comment — restates what the code does.
Suggested change
// same thing either way.

github-actions · 2026-07-31T13:31:48Z

+// teardown together.
+
+// Not the document's failure to render: a journal that no longer describes
+// this run, or a policy that has already decided the document fails.


Redundant comment — restates what the code does.
Suggested change
// this run, or a policy that has already decided the document fails.

github-actions · 2026-07-31T13:31:48Z

 ): FunctionComponentDefinition {
- return { kind: "function", name, props: NO_PROPS, fn: body };
+ // These fixtures exist to be observed failing, so they collect rather than
+ // stopping the expansion the assertion is about.


Redundant comment — restates what the code does.
Suggested change
// stopping the expansion the assertion is about.

github-actions · 2026-07-31T13:32:01Z

PR #251: 💥 Fail fast on function-component failures, collect explicitly

22 files, +737 / -463

Scope

🔴 PR has 1200 lines changed. Split into focused PRs.

🟡 1200 lines changed. PRs under 400 receive more thorough review.

🟡 22 files changed. Are all changes related?

Structural

🟡 Type declarations with no consumers: FatalFailure.

Symbol	Declared at	Refs in diff	Why flagged
`FatalFailure`	`packages/core/src/errors.ts:131`	1	referenced ≤1× within the added diff (pre-existing usages not counted)

Slop

✅ Slop indicators look low.

Static Analysis

✅ Oxlint found no issues.

Correctness

No extraneous code patterns detected.

taras · 2026-07-31T13:31:06Z

Why

Function-component failures were collected into ErrorSegments by default, with fatality an opt-in carried by an internal abort marker. That is inverted: a component that fails now fails the operation it is part of, like any other Effection work, and continuing is an explicit scope-local choice.

Closes#249.

What changes

Default. An ordinary failure propagates after the invocation has been dismantled — projected content, then the component's own resources, then retained work. An Error propagates by identity with its type and cause; a non-Error becomes an Error carrying the original value as cause; body-plus-teardown propagates as the complete aggregate withInvocation() produced. Later siblings do not run.

Component.handleFailure(failure) is the one contextual seam. The default fails the operation. It is called only for an ordinary invocation failure and only after complete teardown. Durability failures, an already-selected DocumentationError, the content transport, and schema diagnostics are classified before it and never reach it.

Two collection forms, one middleware.collectFailures(fn) marks a component by exact function identity and returns the same object. <CollectFailures> is reserved engine syntax that expands its content in the caller's frame, preserving structured segments. Both install the same terminal middleware, so the nearest boundary handles a failure once.

Collection converts a failure into one diagnostic whose cause is the complete original, and does not change the ambient policy — under documentation a collected failure still stops the document.

How it works

The boundary is installed outside the whole withInvocation() call, and scoped:

scoped:
useFailureCollection() ← still installed during teardown
withInvocation:
definition.fn(props)
ordered teardown ← a failure here is still inside the boundary
catch → classify → handleFailure()

Outside, because middleware a component installs for itself is gone before its own teardown can fail. Scoped, because a component that collects its own failures must not quietly decide that for its siblings.

Removed

abortOrdinaryComponentFailures, abortsOrdinaryComponentFailures, the function-identity abort weak set, componentAbort, its error weak set, the aborted arm of fatalCause, hasOrdinaryFailure with its traversal, the agent fatally() wrappers, and the AgentProvider decoration. Agent components now simply throw; they stay fail-fast because that is the default.

Kept and updated: withInvocation(), InvocationTeardownError, durability precedence, AmbientErrorPolicy/settle()/DocumentationError, Component.raise and exactly-once observation, cause attribution, ContentError/tryContent()/the content transport.

What this changed for existing components

Core's <File>, <Glob>, <Parse>, <SafeParse> and <TempDir> have documented diagnostic-and-continue behavior — 44 tests assert it — so they are marked collectFailures(...). That is the decorator's purpose, and it preserves their behavior exactly rather than changing it in a refactor.

Test fixtures whose point is observing a diagnostic are likewise marked; fixtures asserting engine defaults were updated to the new semantics.

How to verify it

Tier CF (tests/failure-collection.test.ts), 11 cases covering the issue's matrix. Every one distinguishes a failed operation from a completed one containing a diagnostic — output text alone cannot tell those apart:

CF1–CF4: unmarked failure by identity with nothing after it; teardown-only; body-plus-teardown aggregate; non-Error normalization with the exact value in cause.
CF5–CF7: collectFailures reports once and continues; the marker is identity, not name; it collects a teardown-only failure.
CF8–CF11: <CollectFailures> handles a direct child and continues; reaches a nested component's failure and handles it once; does not collect durability; under a throwing policy reports once and still stops.

FC5/FC5b pin both halves end-to-end through execute(): an unmarked repository component fails the execution with nothing rendered, and the same component marked reports and continues.

Gate on Deno 2.9.1: fmt / lint / check / test (272 passed, 0 failed) / check:jsr, pnpm exec tsc --project tsconfig.node.json --noEmit, deno task build && ./dist/xmd test packages/core/src --raw (exit 0, 0 failures), git diff --check.

Scope

Per the issue: no WebForm, no Elicit, no remaining #202 migrations, and the TD8 daemon-liveness defect (#248) is deliberately not fixed here.

#247 stays open and will be rebased on this.

An ordinary failure now fails the operation it is part of, after the invocation has been dismantled. Continuing is a scope-local choice: collectFailures(fn) for a component, <CollectFailures> for a region. Closes#249.

github-actions

Found 5 redundant comments. Inline suggestions to remove them below.

github-actions · 2026-07-31T13:31:48Z

+ // deno-lint-ignore require-yield
+ *handleFailure(failure: ComponentFailure): Operation<ErrorSegment> {
+ // The default is to fail, so a component that goes wrong stops the work it
+ // was part of rather than quietly becoming a note in the output.


Redundant comment — restates what the code does.
Suggested change
// was part of rather than quietly becoming a note in the output.

github-actions · 2026-07-31T13:31:48Z

+ /** The invocation itself, and what a failure of it means. */
+ const invoke = function* (): Operation<Segment[]> {
+ // Detached and frozen: what a component reads about its call site is a copy,
+ // so nothing it does can reach the element the parser built.


Redundant comment — restates what the code does.
Suggested change
// so nothing it does can reach the element the parser built.

github-actions · 2026-07-31T13:31:48Z

+ const outcome = yield* handle.tryProject({ kind: "slot", name: slotName });
+ // A documentation failure is presented in the public shape, as
+ // `content()` does, so a component recovering from one sees the
+ // same thing either way.


Redundant comment — restates what the code does.
Suggested change
// same thing either way.

github-actions · 2026-07-31T13:31:48Z

+// teardown together.
+
+// Not the document's failure to render: a journal that no longer describes
+// this run, or a policy that has already decided the document fails.


Redundant comment — restates what the code does.
Suggested change
// this run, or a policy that has already decided the document fails.

github-actions · 2026-07-31T13:31:48Z

 ): FunctionComponentDefinition {
- return { kind: "function", name, props: NO_PROPS, fn: body };
+ // These fixtures exist to be observed failing, so they collect rather than
+ // stopping the expansion the assertion is about.


Redundant comment — restates what the code does.
Suggested change
// stopping the expansion the assertion is about.

github-actions · 2026-07-31T13:32:01Z

PR #251: 💥 Fail fast on function-component failures, collect explicitly

22 files, +737 / -463

Scope

🔴 PR has 1200 lines changed. Split into focused PRs.

🟡 1200 lines changed. PRs under 400 receive more thorough review.

🟡 22 files changed. Are all changes related?

Structural

🟡 Type declarations with no consumers: FatalFailure.

Symbol	Declared at	Refs in diff	Why flagged
`FatalFailure`	`packages/core/src/errors.ts:131`	1	referenced ≤1× within the added diff (pre-existing usages not counted)

Slop

✅ Slop indicators look low.

Static Analysis

✅ Oxlint found no issues.

Correctness

No extraneous code patterns detected.

taras · 2026-07-31T13:31:06Z

Why

Function-component failures were collected into ErrorSegments by default, with fatality an opt-in carried by an internal abort marker. That is inverted: a component that fails now fails the operation it is part of, like any other Effection work, and continuing is an explicit scope-local choice.

Closes#249.

What changes

Default. An ordinary failure propagates after the invocation has been dismantled — projected content, then the component's own resources, then retained work. An Error propagates by identity with its type and cause; a non-Error becomes an Error carrying the original value as cause; body-plus-teardown propagates as the complete aggregate withInvocation() produced. Later siblings do not run.

Component.handleFailure(failure) is the one contextual seam. The default fails the operation. It is called only for an ordinary invocation failure and only after complete teardown. Durability failures, an already-selected DocumentationError, the content transport, and schema diagnostics are classified before it and never reach it.

Two collection forms, one middleware.collectFailures(fn) marks a component by exact function identity and returns the same object. <CollectFailures> is reserved engine syntax that expands its content in the caller's frame, preserving structured segments. Both install the same terminal middleware, so the nearest boundary handles a failure once.

Collection converts a failure into one diagnostic whose cause is the complete original, and does not change the ambient policy — under documentation a collected failure still stops the document.

How it works

The boundary is installed outside the whole withInvocation() call, and scoped:

scoped:
useFailureCollection() ← still installed during teardown
withInvocation:
definition.fn(props)
ordered teardown ← a failure here is still inside the boundary
catch → classify → handleFailure()

Outside, because middleware a component installs for itself is gone before its own teardown can fail. Scoped, because a component that collects its own failures must not quietly decide that for its siblings.

Removed

abortOrdinaryComponentFailures, abortsOrdinaryComponentFailures, the function-identity abort weak set, componentAbort, its error weak set, the aborted arm of fatalCause, hasOrdinaryFailure with its traversal, the agent fatally() wrappers, and the AgentProvider decoration. Agent components now simply throw; they stay fail-fast because that is the default.

Kept and updated: withInvocation(), InvocationTeardownError, durability precedence, AmbientErrorPolicy/settle()/DocumentationError, Component.raise and exactly-once observation, cause attribution, ContentError/tryContent()/the content transport.

What this changed for existing components

Core's <File>, <Glob>, <Parse>, <SafeParse> and <TempDir> have documented diagnostic-and-continue behavior — 44 tests assert it — so they are marked collectFailures(...). That is the decorator's purpose, and it preserves their behavior exactly rather than changing it in a refactor.

Test fixtures whose point is observing a diagnostic are likewise marked; fixtures asserting engine defaults were updated to the new semantics.

How to verify it

Tier CF (tests/failure-collection.test.ts), 11 cases covering the issue's matrix. Every one distinguishes a failed operation from a completed one containing a diagnostic — output text alone cannot tell those apart:

CF1–CF4: unmarked failure by identity with nothing after it; teardown-only; body-plus-teardown aggregate; non-Error normalization with the exact value in cause.
CF5–CF7: collectFailures reports once and continues; the marker is identity, not name; it collects a teardown-only failure.
CF8–CF11: <CollectFailures> handles a direct child and continues; reaches a nested component's failure and handles it once; does not collect durability; under a throwing policy reports once and still stops.

FC5/FC5b pin both halves end-to-end through execute(): an unmarked repository component fails the execution with nothing rendered, and the same component marked reports and continues.

Gate on Deno 2.9.1: fmt / lint / check / test (272 passed, 0 failed) / check:jsr, pnpm exec tsc --project tsconfig.node.json --noEmit, deno task build && ./dist/xmd test packages/core/src --raw (exit 0, 0 failures), git diff --check.

Scope

Per the issue: no WebForm, no Elicit, no remaining #202 migrations, and the TD8 daemon-liveness defect (#248) is deliberately not fixed here.

#247 stays open and will be rebased on this.

An ordinary failure now fails the operation it is part of, after the invocation has been dismantled. Continuing is a scope-local choice: collectFailures(fn) for a component, <CollectFailures> for a region. Closes#249.

github-actions

Found 5 redundant comments. Inline suggestions to remove them below.

github-actions · 2026-07-31T13:31:48Z

+ // deno-lint-ignore require-yield
+ *handleFailure(failure: ComponentFailure): Operation<ErrorSegment> {
+ // The default is to fail, so a component that goes wrong stops the work it
+ // was part of rather than quietly becoming a note in the output.


Redundant comment — restates what the code does.
Suggested change
// was part of rather than quietly becoming a note in the output.

github-actions · 2026-07-31T13:31:48Z

+ /** The invocation itself, and what a failure of it means. */
+ const invoke = function* (): Operation<Segment[]> {
+ // Detached and frozen: what a component reads about its call site is a copy,
+ // so nothing it does can reach the element the parser built.


Redundant comment — restates what the code does.
Suggested change
// so nothing it does can reach the element the parser built.

github-actions · 2026-07-31T13:31:48Z

+ const outcome = yield* handle.tryProject({ kind: "slot", name: slotName });
+ // A documentation failure is presented in the public shape, as
+ // `content()` does, so a component recovering from one sees the
+ // same thing either way.


Redundant comment — restates what the code does.
Suggested change
// same thing either way.

github-actions · 2026-07-31T13:31:48Z

+// teardown together.
+
+// Not the document's failure to render: a journal that no longer describes
+// this run, or a policy that has already decided the document fails.


Redundant comment — restates what the code does.
Suggested change
// this run, or a policy that has already decided the document fails.

github-actions · 2026-07-31T13:31:48Z

 ): FunctionComponentDefinition {
- return { kind: "function", name, props: NO_PROPS, fn: body };
+ // These fixtures exist to be observed failing, so they collect rather than
+ // stopping the expansion the assertion is about.


Redundant comment — restates what the code does.
Suggested change
// stopping the expansion the assertion is about.

github-actions · 2026-07-31T13:32:01Z

PR #251: 💥 Fail fast on function-component failures, collect explicitly

22 files, +737 / -463

Scope

🔴 PR has 1200 lines changed. Split into focused PRs.

🟡 1200 lines changed. PRs under 400 receive more thorough review.

🟡 22 files changed. Are all changes related?

Structural

🟡 Type declarations with no consumers: FatalFailure.

Symbol	Declared at	Refs in diff	Why flagged
`FatalFailure`	`packages/core/src/errors.ts:131`	1	referenced ≤1× within the added diff (pre-existing usages not counted)

Slop

✅ Slop indicators look low.

Static Analysis

✅ Oxlint found no issues.

Correctness

No extraneous code patterns detected.

taras · 2026-07-31T13:31:06Z

Why

Function-component failures were collected into ErrorSegments by default, with fatality an opt-in carried by an internal abort marker. That is inverted: a component that fails now fails the operation it is part of, like any other Effection work, and continuing is an explicit scope-local choice.

Closes#249.

What changes

Default. An ordinary failure propagates after the invocation has been dismantled — projected content, then the component's own resources, then retained work. An Error propagates by identity with its type and cause; a non-Error becomes an Error carrying the original value as cause; body-plus-teardown propagates as the complete aggregate withInvocation() produced. Later siblings do not run.

Component.handleFailure(failure) is the one contextual seam. The default fails the operation. It is called only for an ordinary invocation failure and only after complete teardown. Durability failures, an already-selected DocumentationError, the content transport, and schema diagnostics are classified before it and never reach it.

Two collection forms, one middleware.collectFailures(fn) marks a component by exact function identity and returns the same object. <CollectFailures> is reserved engine syntax that expands its content in the caller's frame, preserving structured segments. Both install the same terminal middleware, so the nearest boundary handles a failure once.

Collection converts a failure into one diagnostic whose cause is the complete original, and does not change the ambient policy — under documentation a collected failure still stops the document.

How it works

The boundary is installed outside the whole withInvocation() call, and scoped:

scoped:
useFailureCollection() ← still installed during teardown
withInvocation:
definition.fn(props)
ordered teardown ← a failure here is still inside the boundary
catch → classify → handleFailure()

Outside, because middleware a component installs for itself is gone before its own teardown can fail. Scoped, because a component that collects its own failures must not quietly decide that for its siblings.

Removed

abortOrdinaryComponentFailures, abortsOrdinaryComponentFailures, the function-identity abort weak set, componentAbort, its error weak set, the aborted arm of fatalCause, hasOrdinaryFailure with its traversal, the agent fatally() wrappers, and the AgentProvider decoration. Agent components now simply throw; they stay fail-fast because that is the default.

Kept and updated: withInvocation(), InvocationTeardownError, durability precedence, AmbientErrorPolicy/settle()/DocumentationError, Component.raise and exactly-once observation, cause attribution, ContentError/tryContent()/the content transport.

What this changed for existing components

Core's <File>, <Glob>, <Parse>, <SafeParse> and <TempDir> have documented diagnostic-and-continue behavior — 44 tests assert it — so they are marked collectFailures(...). That is the decorator's purpose, and it preserves their behavior exactly rather than changing it in a refactor.

Test fixtures whose point is observing a diagnostic are likewise marked; fixtures asserting engine defaults were updated to the new semantics.

How to verify it

Tier CF (tests/failure-collection.test.ts), 11 cases covering the issue's matrix. Every one distinguishes a failed operation from a completed one containing a diagnostic — output text alone cannot tell those apart:

CF1–CF4: unmarked failure by identity with nothing after it; teardown-only; body-plus-teardown aggregate; non-Error normalization with the exact value in cause.
CF5–CF7: collectFailures reports once and continues; the marker is identity, not name; it collects a teardown-only failure.
CF8–CF11: <CollectFailures> handles a direct child and continues; reaches a nested component's failure and handles it once; does not collect durability; under a throwing policy reports once and still stops.

FC5/FC5b pin both halves end-to-end through execute(): an unmarked repository component fails the execution with nothing rendered, and the same component marked reports and continues.

Gate on Deno 2.9.1: fmt / lint / check / test (272 passed, 0 failed) / check:jsr, pnpm exec tsc --project tsconfig.node.json --noEmit, deno task build && ./dist/xmd test packages/core/src --raw (exit 0, 0 failures), git diff --check.

Scope

Per the issue: no WebForm, no Elicit, no remaining #202 migrations, and the TD8 daemon-liveness defect (#248) is deliberately not fixed here.

#247 stays open and will be rebased on this.

An ordinary failure now fails the operation it is part of, after the invocation has been dismantled. Continuing is a scope-local choice: collectFailures(fn) for a component, <CollectFailures> for a region. Closes#249.

github-actions

Found 5 redundant comments. Inline suggestions to remove them below.

github-actions · 2026-07-31T13:31:48Z

+ // deno-lint-ignore require-yield
+ *handleFailure(failure: ComponentFailure): Operation<ErrorSegment> {
+ // The default is to fail, so a component that goes wrong stops the work it
+ // was part of rather than quietly becoming a note in the output.


Redundant comment — restates what the code does.
Suggested change
// was part of rather than quietly becoming a note in the output.

github-actions · 2026-07-31T13:31:48Z

+ /** The invocation itself, and what a failure of it means. */
+ const invoke = function* (): Operation<Segment[]> {
+ // Detached and frozen: what a component reads about its call site is a copy,
+ // so nothing it does can reach the element the parser built.


Redundant comment — restates what the code does.
Suggested change
// so nothing it does can reach the element the parser built.

github-actions · 2026-07-31T13:31:48Z

+ const outcome = yield* handle.tryProject({ kind: "slot", name: slotName });
+ // A documentation failure is presented in the public shape, as
+ // `content()` does, so a component recovering from one sees the
+ // same thing either way.


Redundant comment — restates what the code does.
Suggested change
// same thing either way.

github-actions · 2026-07-31T13:31:48Z

+// teardown together.
+
+// Not the document's failure to render: a journal that no longer describes
+// this run, or a policy that has already decided the document fails.


Redundant comment — restates what the code does.
Suggested change
// this run, or a policy that has already decided the document fails.

github-actions · 2026-07-31T13:31:48Z

 ): FunctionComponentDefinition {
- return { kind: "function", name, props: NO_PROPS, fn: body };
+ // These fixtures exist to be observed failing, so they collect rather than
+ // stopping the expansion the assertion is about.


Redundant comment — restates what the code does.
Suggested change
// stopping the expansion the assertion is about.

github-actions · 2026-07-31T13:32:01Z

PR #251: 💥 Fail fast on function-component failures, collect explicitly

22 files, +737 / -463

Scope

🔴 PR has 1200 lines changed. Split into focused PRs.

🟡 1200 lines changed. PRs under 400 receive more thorough review.

🟡 22 files changed. Are all changes related?

Structural

🟡 Type declarations with no consumers: FatalFailure.

Symbol	Declared at	Refs in diff	Why flagged
`FatalFailure`	`packages/core/src/errors.ts:131`	1	referenced ≤1× within the added diff (pre-existing usages not counted)

Slop

✅ Slop indicators look low.

Static Analysis

✅ Oxlint found no issues.

Correctness

No extraneous code patterns detected.

taras · 2026-07-31T13:31:06Z

Why

Function-component failures were collected into ErrorSegments by default, with fatality an opt-in carried by an internal abort marker. That is inverted: a component that fails now fails the operation it is part of, like any other Effection work, and continuing is an explicit scope-local choice.

Closes#249.

What changes

Default. An ordinary failure propagates after the invocation has been dismantled — projected content, then the component's own resources, then retained work. An Error propagates by identity with its type and cause; a non-Error becomes an Error carrying the original value as cause; body-plus-teardown propagates as the complete aggregate withInvocation() produced. Later siblings do not run.

Component.handleFailure(failure) is the one contextual seam. The default fails the operation. It is called only for an ordinary invocation failure and only after complete teardown. Durability failures, an already-selected DocumentationError, the content transport, and schema diagnostics are classified before it and never reach it.

Two collection forms, one middleware.collectFailures(fn) marks a component by exact function identity and returns the same object. <CollectFailures> is reserved engine syntax that expands its content in the caller's frame, preserving structured segments. Both install the same terminal middleware, so the nearest boundary handles a failure once.

Collection converts a failure into one diagnostic whose cause is the complete original, and does not change the ambient policy — under documentation a collected failure still stops the document.

How it works

The boundary is installed outside the whole withInvocation() call, and scoped:

scoped:
useFailureCollection() ← still installed during teardown
withInvocation:
definition.fn(props)
ordered teardown ← a failure here is still inside the boundary
catch → classify → handleFailure()

Outside, because middleware a component installs for itself is gone before its own teardown can fail. Scoped, because a component that collects its own failures must not quietly decide that for its siblings.

Removed

abortOrdinaryComponentFailures, abortsOrdinaryComponentFailures, the function-identity abort weak set, componentAbort, its error weak set, the aborted arm of fatalCause, hasOrdinaryFailure with its traversal, the agent fatally() wrappers, and the AgentProvider decoration. Agent components now simply throw; they stay fail-fast because that is the default.

Kept and updated: withInvocation(), InvocationTeardownError, durability precedence, AmbientErrorPolicy/settle()/DocumentationError, Component.raise and exactly-once observation, cause attribution, ContentError/tryContent()/the content transport.

What this changed for existing components

Core's <File>, <Glob>, <Parse>, <SafeParse> and <TempDir> have documented diagnostic-and-continue behavior — 44 tests assert it — so they are marked collectFailures(...). That is the decorator's purpose, and it preserves their behavior exactly rather than changing it in a refactor.

Test fixtures whose point is observing a diagnostic are likewise marked; fixtures asserting engine defaults were updated to the new semantics.

How to verify it

Tier CF (tests/failure-collection.test.ts), 11 cases covering the issue's matrix. Every one distinguishes a failed operation from a completed one containing a diagnostic — output text alone cannot tell those apart:

CF1–CF4: unmarked failure by identity with nothing after it; teardown-only; body-plus-teardown aggregate; non-Error normalization with the exact value in cause.
CF5–CF7: collectFailures reports once and continues; the marker is identity, not name; it collects a teardown-only failure.
CF8–CF11: <CollectFailures> handles a direct child and continues; reaches a nested component's failure and handles it once; does not collect durability; under a throwing policy reports once and still stops.

FC5/FC5b pin both halves end-to-end through execute(): an unmarked repository component fails the execution with nothing rendered, and the same component marked reports and continues.

Gate on Deno 2.9.1: fmt / lint / check / test (272 passed, 0 failed) / check:jsr, pnpm exec tsc --project tsconfig.node.json --noEmit, deno task build && ./dist/xmd test packages/core/src --raw (exit 0, 0 failures), git diff --check.

Scope

Per the issue: no WebForm, no Elicit, no remaining #202 migrations, and the TD8 daemon-liveness defect (#248) is deliberately not fixed here.

#247 stays open and will be rebased on this.

An ordinary failure now fails the operation it is part of, after the invocation has been dismantled. Continuing is a scope-local choice: collectFailures(fn) for a component, <CollectFailures> for a region. Closes#249.

github-actions

Found 5 redundant comments. Inline suggestions to remove them below.

github-actions · 2026-07-31T13:31:48Z

+ // deno-lint-ignore require-yield
+ *handleFailure(failure: ComponentFailure): Operation<ErrorSegment> {
+ // The default is to fail, so a component that goes wrong stops the work it
+ // was part of rather than quietly becoming a note in the output.


Redundant comment — restates what the code does.
Suggested change
// was part of rather than quietly becoming a note in the output.

github-actions · 2026-07-31T13:31:48Z

+ /** The invocation itself, and what a failure of it means. */
+ const invoke = function* (): Operation<Segment[]> {
+ // Detached and frozen: what a component reads about its call site is a copy,
+ // so nothing it does can reach the element the parser built.


Redundant comment — restates what the code does.
Suggested change
// so nothing it does can reach the element the parser built.

github-actions · 2026-07-31T13:31:48Z

+ const outcome = yield* handle.tryProject({ kind: "slot", name: slotName });
+ // A documentation failure is presented in the public shape, as
+ // `content()` does, so a component recovering from one sees the
+ // same thing either way.


Redundant comment — restates what the code does.
Suggested change
// same thing either way.

github-actions · 2026-07-31T13:31:48Z

+// teardown together.
+
+// Not the document's failure to render: a journal that no longer describes
+// this run, or a policy that has already decided the document fails.


Redundant comment — restates what the code does.
Suggested change
// this run, or a policy that has already decided the document fails.

github-actions · 2026-07-31T13:31:48Z

 ): FunctionComponentDefinition {
- return { kind: "function", name, props: NO_PROPS, fn: body };
+ // These fixtures exist to be observed failing, so they collect rather than
+ // stopping the expansion the assertion is about.


Redundant comment — restates what the code does.
Suggested change
// stopping the expansion the assertion is about.

github-actions · 2026-07-31T13:32:01Z

PR #251: 💥 Fail fast on function-component failures, collect explicitly

22 files, +737 / -463

Scope

🔴 PR has 1200 lines changed. Split into focused PRs.

🟡 1200 lines changed. PRs under 400 receive more thorough review.

🟡 22 files changed. Are all changes related?

Structural

🟡 Type declarations with no consumers: FatalFailure.

Symbol	Declared at	Refs in diff	Why flagged
`FatalFailure`	`packages/core/src/errors.ts:131`	1	referenced ≤1× within the added diff (pre-existing usages not counted)

Slop

✅ Slop indicators look low.

Static Analysis

✅ Oxlint found no issues.

Correctness

No extraneous code patterns detected.

taras · 2026-07-31T13:31:06Z

Why

Function-component failures were collected into ErrorSegments by default, with fatality an opt-in carried by an internal abort marker. That is inverted: a component that fails now fails the operation it is part of, like any other Effection work, and continuing is an explicit scope-local choice.

Closes#249.

What changes

Default. An ordinary failure propagates after the invocation has been dismantled — projected content, then the component's own resources, then retained work. An Error propagates by identity with its type and cause; a non-Error becomes an Error carrying the original value as cause; body-plus-teardown propagates as the complete aggregate withInvocation() produced. Later siblings do not run.

Component.handleFailure(failure) is the one contextual seam. The default fails the operation. It is called only for an ordinary invocation failure and only after complete teardown. Durability failures, an already-selected DocumentationError, the content transport, and schema diagnostics are classified before it and never reach it.

Two collection forms, one middleware.collectFailures(fn) marks a component by exact function identity and returns the same object. <CollectFailures> is reserved engine syntax that expands its content in the caller's frame, preserving structured segments. Both install the same terminal middleware, so the nearest boundary handles a failure once.

Collection converts a failure into one diagnostic whose cause is the complete original, and does not change the ambient policy — under documentation a collected failure still stops the document.

How it works

The boundary is installed outside the whole withInvocation() call, and scoped:

scoped:
useFailureCollection() ← still installed during teardown
withInvocation:
definition.fn(props)
ordered teardown ← a failure here is still inside the boundary
catch → classify → handleFailure()

Outside, because middleware a component installs for itself is gone before its own teardown can fail. Scoped, because a component that collects its own failures must not quietly decide that for its siblings.

Removed

abortOrdinaryComponentFailures, abortsOrdinaryComponentFailures, the function-identity abort weak set, componentAbort, its error weak set, the aborted arm of fatalCause, hasOrdinaryFailure with its traversal, the agent fatally() wrappers, and the AgentProvider decoration. Agent components now simply throw; they stay fail-fast because that is the default.

Kept and updated: withInvocation(), InvocationTeardownError, durability precedence, AmbientErrorPolicy/settle()/DocumentationError, Component.raise and exactly-once observation, cause attribution, ContentError/tryContent()/the content transport.

What this changed for existing components

Core's <File>, <Glob>, <Parse>, <SafeParse> and <TempDir> have documented diagnostic-and-continue behavior — 44 tests assert it — so they are marked collectFailures(...). That is the decorator's purpose, and it preserves their behavior exactly rather than changing it in a refactor.

Test fixtures whose point is observing a diagnostic are likewise marked; fixtures asserting engine defaults were updated to the new semantics.

How to verify it

Tier CF (tests/failure-collection.test.ts), 11 cases covering the issue's matrix. Every one distinguishes a failed operation from a completed one containing a diagnostic — output text alone cannot tell those apart:

CF1–CF4: unmarked failure by identity with nothing after it; teardown-only; body-plus-teardown aggregate; non-Error normalization with the exact value in cause.
CF5–CF7: collectFailures reports once and continues; the marker is identity, not name; it collects a teardown-only failure.
CF8–CF11: <CollectFailures> handles a direct child and continues; reaches a nested component's failure and handles it once; does not collect durability; under a throwing policy reports once and still stops.

FC5/FC5b pin both halves end-to-end through execute(): an unmarked repository component fails the execution with nothing rendered, and the same component marked reports and continues.

Gate on Deno 2.9.1: fmt / lint / check / test (272 passed, 0 failed) / check:jsr, pnpm exec tsc --project tsconfig.node.json --noEmit, deno task build && ./dist/xmd test packages/core/src --raw (exit 0, 0 failures), git diff --check.

Scope

Per the issue: no WebForm, no Elicit, no remaining #202 migrations, and the TD8 daemon-liveness defect (#248) is deliberately not fixed here.

#247 stays open and will be rebased on this.

An ordinary failure now fails the operation it is part of, after the invocation has been dismantled. Continuing is a scope-local choice: collectFailures(fn) for a component, <CollectFailures> for a region. Closes#249.

github-actions

Found 5 redundant comments. Inline suggestions to remove them below.

github-actions · 2026-07-31T13:31:48Z

+ // deno-lint-ignore require-yield
+ *handleFailure(failure: ComponentFailure): Operation<ErrorSegment> {
+ // The default is to fail, so a component that goes wrong stops the work it
+ // was part of rather than quietly becoming a note in the output.


Redundant comment — restates what the code does.
Suggested change
// was part of rather than quietly becoming a note in the output.

github-actions · 2026-07-31T13:31:48Z

+ /** The invocation itself, and what a failure of it means. */
+ const invoke = function* (): Operation<Segment[]> {
+ // Detached and frozen: what a component reads about its call site is a copy,
+ // so nothing it does can reach the element the parser built.


Redundant comment — restates what the code does.
Suggested change
// so nothing it does can reach the element the parser built.

github-actions · 2026-07-31T13:31:48Z

+ const outcome = yield* handle.tryProject({ kind: "slot", name: slotName });
+ // A documentation failure is presented in the public shape, as
+ // `content()` does, so a component recovering from one sees the
+ // same thing either way.


Redundant comment — restates what the code does.
Suggested change
// same thing either way.

github-actions · 2026-07-31T13:31:48Z

+// teardown together.
+
+// Not the document's failure to render: a journal that no longer describes
+// this run, or a policy that has already decided the document fails.


Redundant comment — restates what the code does.
Suggested change
// this run, or a policy that has already decided the document fails.

github-actions · 2026-07-31T13:31:48Z

 ): FunctionComponentDefinition {
- return { kind: "function", name, props: NO_PROPS, fn: body };
+ // These fixtures exist to be observed failing, so they collect rather than
+ // stopping the expansion the assertion is about.


Redundant comment — restates what the code does.
Suggested change
// stopping the expansion the assertion is about.

github-actions · 2026-07-31T13:32:01Z

PR #251: 💥 Fail fast on function-component failures, collect explicitly

22 files, +737 / -463

Scope

🔴 PR has 1200 lines changed. Split into focused PRs.

🟡 1200 lines changed. PRs under 400 receive more thorough review.

🟡 22 files changed. Are all changes related?

Structural

🟡 Type declarations with no consumers: FatalFailure.

Symbol	Declared at	Refs in diff	Why flagged
`FatalFailure`	`packages/core/src/errors.ts:131`	1	referenced ≤1× within the added diff (pre-existing usages not counted)

Slop

✅ Slop indicators look low.

Static Analysis

✅ Oxlint found no issues.

Correctness

No extraneous code patterns detected.

💥 Fail fast on function-component failures, collect explicitly
e1ed5b1
An ordinary failure now fails the operation it is part of, after the invocation has been dismantled. Continuing is a scope-local choice: collectFailures(fn) for a component, <CollectFailures> for a region. Closes#249.

github-actionsBot reviewed Jul 31, 2026
View reviewed changes

taras merged commit 97d9c35 into mainJul 31, 2026
9 checks passed

This was referenced Jul 31, 2026
✨ feat: the WebForm component, live form, and durability (#195) #252
Merged
🐛 Reject props on <CollectFailures>, and prove what collection does #253
Merged
Add <Answers>: provide elicitation responses as a document construct #267
Closed

taras deleted the feat/fail-fast-components branch August 27, 2026 01:34