fail-closed-on-inherited-visibility

Enforces fail-closed handling when ledger events inherit visibility from referenced events.

Updated Jul 9, 2026
One-click install
npx skills add https://github.com/shuddl/shuddl-os --skill fail-closed-on-inherited-visibility-shuddl
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: fail-closed-on-inherited-visibility
Source: https://github.com/shuddl/shuddl-os/tree/main/.claude/skills/fail-closed-on-inherited-visibility
Command: npx skills add https://github.com/shuddl/shuddl-os --skill fail-closed-on-inherited-visibility-shuddl

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When a ledger event inherits a security attribute (visibility, division, party, floor) from a referenced event, an unresolved reference can silently fall through to the kind's open default, leaking data into wider lenses than the original event allowed. This Skill defines the rule and fix pattern to make such misses hard errors instead of silent widening. ## Core Features & Use Cases - Defect diagnosis: Identifies the truthiness-guard anti-pattern (&& value) in visibility resolution that skips inheritance on undefined and falls through to open defaults like counterparty. - Fail-closed fix pattern: Provides the corrected code shape — explicit === undefined checks that throw or resolve to the most-restrictive rank (internal), plus append-path rejection when corrects_event_id resolves to zero rows. - Use Case: While reviewing resolveVisibility for invoice.corrected netting, an engineer finds a correction stamped wider than the invoice it nets; this Skill supplies the rule, the fix, and the test recipe to close the leak and replace the blessing test. ## Quick Start Review the invoice.corrected visibility resolution in packages/ledger/src/visibility.ts and apply the fail-closed rule so unresolved corrects_event_id references throw instead of defaulting to counterparty.

Frequently Asked Questions about fail-closed-on-inherited-visibility

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I handle inherited visibility when the referenced event is missing?▼

Treat a missing inherited visibility as a hard error: throw, or fail closed to the most-restrictive rank such as internal. Never fall through to the event kind's open default like counterparty, since that widens disclosure beyond the original event.

Why is a truthiness guard wrong for inherited security attributes?▼

A guard like `&& value` treats undefined or falsy inherited values as absent and skips the inheritance branch, falling through to defaults. Use an explicit `=== undefined` check so a failed lookup is detected and rejected instead of silently bypassed.

What should happen when corrects_event_id resolves to zero rows?▼

The append should be rejected rather than letting the lookup return undefined downstream. Allowing the append to continue produces a correction stamped at the kind default, which can be wider than the invoice it nets.

When does this fail-closed rule not apply?▼

It does not apply to values the caller legitimately owns, such as a per-event requested narrowing, which is advisory and may be absent. The rule governs only inherited security attributes like visibility, division, party, and floor.

How do I test that corrections never widen visibility?▼

Feed each inheriting kind an unresolved parent so the inherited value is undefined, then assert the result throws or resolves to internal, never the kind's counterparty or public default. Add a case where the corrected invoice was internal and confirm the correction never resolves wider.