UNPKG

@crossplatformai/skills

Version:

Reusable Agent Skills for CrossPlatform.ai projects.

github.com/crossplatformai/framework

crossplatformai/framework

52 lines (36 loc) • 2.31 kB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
# Fail Fast Over Fallbacks Shared reference for `post`, `build`, and `ship`. This is the canonical implementation-fallback policy. The skills carry a one-line stance inline and defer the full rule here; they must not restate a divergent version. ## Stance Default engineering stance for `post`, `build`, and `ship`: prefer fail-fast over fallbacks. This policy governs planned and implemented behavior. It does not turn an optional review finding or a QA retry into approval authority. ## What counts as a fallback A fallback is alternate behavior that lets execution continue past a missing or failed condition, including: 1. alternate behavior after missing or failed required config, data, API response, or state 2. silent catch-and-continue that swallows an error 3. a compatibility shim that hides an unresolved incompatibility 4. a default value substituted for a missing or failed required input; pure functional defaults for genuinely optional inputs are not fallbacks 5. a retry or alternate route that masks a root cause 6. a redundant alternate navigation or data path where one path should be authoritative, which can mask which path actually runs Fail-fast means surfacing the missing condition loudly: throw, return an explicit error, render an explicit error state, or refuse to proceed, so the root cause is visible rather than masked. ## Authorizing User approval Adding any implementation fallback requires explicit user approval. Before adding one, the assistant must explain, in chat: 1. what failure or missing condition the fallback handles 2. why fail-fast is not acceptable here 3. why the fallback is necessary or preferred 4. how it will be tested and observed so a future failure stays visible Until the user approves, plan and implement the fail-fast path. Do not add the fallback. Record any proposed implementation fallback in Risks / Rules and obtain explicit Authorizing User approval before Build adds it. ## Carve-outs These are not implementation fallbacks under this policy and remain governed by their existing rules: the documented database migration-backed QA exception; request-driven happy-path demo accelerations that are already justified in the approved packet; and genuine platform-required branching that still fails loudly on the unexpected case.