[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JWJD9RJHA90WSWYDPCQ7YB":3,"skill-same:01M6JWJD9RJHA90WSWYDPCQ7YB":75},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":48,"repositoryHtmlUrl":49,"repositoryHomepageUrl":50,"ownerHtmlUrl":51,"ownerBlogUrl":52,"ownerDescription":53,"updatedAt":54,"install":55,"resources":68},"01M6JWJD9RJHA90WSWYDPCQ7YB","factor-of-safety",null,"Use this skill whenever the design will encounter conditions that can't be fully predicted at design time — load spikes, edge-case content, real-world variability, hardware variation, third-party flakiness, or any \"what if\" scenario. Trigger when scoping performance budgets, designing for content extremes, picking infrastructure capacity, designing error-handling, or planning for the long tail of users with unusual setups. Factor of Safety is one of the foundational principles in 'Universal Principles of Design' (Lidwell, Holden, Butler 2003) — also called \"factor of ignorance\" because the size of the safety factor is proportional to how much you *don't* know.","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1566,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FHDeibler\u002Funiversal-design-principles\u002Fplugins\u002Fprocess-and-robustness-principles\u002Fskills\u002Ffactor-of-safety\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"factor of safety","Safety","factor","scenario","when","for","at","you","error","long","trigger","butler","design","time","world","scoping","how","edge","planning","infrastructure","performance","2026-11-10 10:12:30",false,"---\nname: factor-of-safety\ndescription: 'Use this skill whenever the design will encounter conditions that can''t be fully predicted at design time — load spikes, edge-case content, real-world variability, hardware variation, third-party flakiness, or any \"what if\" scenario. Trigger when scoping performance budgets, designing for content extremes, picking infrastructure capacity, designing error-handling, or planning for the long tail of users with unusual setups. Factor of Safety is one of the foundational principles in ''Universal Principles of Design'' (Lidwell, Holden, Butler 2003) — also called \"factor of ignorance\" because the size of the safety factor is proportional to how much you *don''t* know.'\n---\n\n# Factor of Safety\n\nFactor of Safety is the engineering practice of designing systems with capacity exceeding what's strictly required, to absorb unknown variations and prevent failure. A bridge rated for 5,000 lbs is built to hold 25,000 — a safety factor of 5. The \"extra\" capacity isn't waste; it's insurance against the things you didn't predict: corrosion, fatigue, unusual load combinations, materials that didn't quite meet spec.\n\nFor software design, the same logic applies: design with margin in performance, capacity, content handling, error tolerance, and edge cases. The unpredicted always shows up; the question is whether the system absorbs it gracefully or fails loudly.\n\n## Definition (in our own words)\n\nA factor of safety is the ratio of a system's actual capacity to the capacity it was designed to handle under normal use. The size of the factor depends on how much you don't know about the conditions the system will face — the more uncertainty, the larger the factor needs to be. The book's alternative name, \"factor of ignorance,\" is illuminating: a well-understood, well-tested system can have a small safety factor; a novel system facing unknown conditions needs a large one.\n\n## Origins and research lineage\n\n- **Engineering safety practice** going back centuries. The Pyramids of Giza, by some analyses, were over-engineered with safety factors of 20+ — the builders couldn't predict load conditions over millennia, so they built radically conservatively.\n- **Henry Petroski**, *To Engineer Is Human: The Role of Failure in Successful Design* (St. Martin's Press, 1985) and *Design Paradigms: Case Histories of Error and Judgment in Engineering* (Cambridge University Press, 1994). Petroski's central thesis: engineering progresses by understanding past failures, and safety factors are the explicit acknowledgment that the next failure will look like something not yet seen.\n- **Lidwell, Holden & Butler** (2003) compactly stated the principle and noted the inverse relationship between safety-factor size and design knowledge. The book's central case: the Challenger O-rings, designed for a safety factor of 3 in past launches but well below 3 at low temperatures.\n- **Modern reliability engineering** (Jens Rasmussen, Charles Perrow's *Normal Accidents*, James Reason's work on system failure) extends the idea to complex systems where multiple small margins compound into total system safety.\n- **Software practice** — capacity planning, redundancy, error budgets (Google SRE), graceful degradation — all are factor-of-safety in software vocabulary.\n\n## Why factor of safety matters\n\nEvery system designed at exactly its expected load will fail when it encounters more. Real systems always encounter more — through use you didn't predict, through growth, through abuse, through the long tail of edge cases. A system without margin fails loudly when conditions change; a system with margin absorbs the change gracefully and continues operating.\n\nThe cost of insufficient margin is well-documented:\n\n- **Performance**: a system sized for 1,000 users that hits 1,500 users degrades or crashes.\n- **Content**: a layout sized for 50-character names breaks when a user has a 90-character name.\n- **Network**: an API designed assuming 99.9% uptime fails when its dependency drops to 98%.\n- **Hardware**: a UI designed for 1080p screens looks broken on 4K and on small mobile.\n- **Cognitive**: a tool designed for the typical user fails for the user with motor impairment, low vision, or unfamiliarity.\n\nThe cost of *too much* margin is real too — over-engineering wastes resources, slows development, and can make systems harder to maintain. The discipline is calibrating margin to the actual uncertainty.\n\n## When to apply\n\n- **Performance and capacity planning.** Systems should run at meaningful headroom over typical load.\n- **Content handling.** Layouts must survive content that exceeds typical bounds — long names, big numbers, multi-line addresses, no images.\n- **Error tolerance.** Systems should fail gracefully on unexpected input rather than crashing.\n- **Network and dependency reliability.** Systems should degrade gracefully when dependencies are slow or down.\n- **Hardware variation.** UIs should work across device sizes, pixel densities, and input modalities.\n- **Accessibility.** Designs should accommodate users at the edges of typical capability ranges.\n- **Anywhere \"we've never seen that before\" is plausible.**\n\n## When NOT to over-apply\n\n- **Premature optimization.** Building 100x capacity when current load is 1x ties up resources better spent on other priorities.\n- **Speculative redundancy.** Multiple redundant systems for failure modes that have never occurred and aren't credible.\n- **Defensive code obscuring intent.** Wrapping every operation in try\u002Fcatch with no error-handling strategy. Doesn't help; obscures.\n\nThe right margin is enough to handle the credible unknown — not infinite.\n\n## How to size the safety factor\n\nThe book's insight: the safety factor should track the level of *ignorance* about the design parameters.\n\n- **Well-understood, well-tested system**: safety factor of 1.5–2x typical load.\n- **Moderately understood, some unknowns**: 2–4x.\n- **Novel system, significant unknowns**: 4–10x or more.\n- **Catastrophic-failure systems with severe consequence**: even higher.\n\nTypical safety factors in different engineering domains:\n\n- Steel structures: 2–3x.\n- Wood structures: 4–6x (more variable material).\n- Aircraft: 1.5x (highly engineered, weight-constrained — but with extensive other safety mechanisms).\n- Software capacity: highly variable, often 2–5x of expected peak load.\n- UI content: typically design for 1.5–2x the typical content length.\n\n## Worked examples\n\n### Example 1: layout that survives content extremes\n\nA user-card layout designed only for short names breaks for the user named \"María-José Esperanza Sánchez de Bermúdez.\"\n\n```css\n\u002F* Without margin *\u002F\n.user-name {\n  width: 200px;\n  white-space: nowrap;\n  overflow: hidden;\n}\n\u002F* Long names disappear into ellipsis silently *\u002F\n\n\u002F* With margin *\u002F\n.user-name {\n  max-width: 100%;\n  overflow-wrap: break-word;\n  hyphens: auto;\n}\n.user-card {\n  min-height: 80px;  \u002F* accommodates 1-3 lines *\u002F\n}\n```\n\nThe \"with margin\" version handles names from 5 to 90 characters; the layout grows gracefully.\n\n### Example 2: API capacity planning\n\nAn API expected to handle 100 requests\u002Fsecond is designed with capacity for 500 rps. Reasoning:\n\n- Marketing campaigns, viral growth, or app launches can spike traffic 5–10x.\n- Slow database queries can multiply effective load.\n- One client misbehaving can saturate the API for everyone.\n\nThe 5x margin handles common spikes; auto-scaling handles sustained growth beyond.\n\n### Example 3: graceful degradation when a dependency fails\n\n```js\nasync function fetchUserData(userId) {\n  try {\n    return await api.fetchUser(userId, { timeout: 2000 });\n  } catch (error) {\n    \u002F\u002F Graceful degradation: return cached data if available\n    const cached = await cache.get(`user:${userId}`);\n    if (cached) {\n      logger.warn('Using cached user data due to API failure', { userId, error });\n      return { ...cached, _stale: true };\n    }\n    \u002F\u002F Last resort: return minimal data so UI can render something\n    return { id: userId, name: 'Unknown', _placeholder: true };\n  }\n}\n```\n\nThree levels of margin: try the API; fall back to cache; fall back to placeholder. The UI never gets a hard crash from a transient failure.\n\n### Example 4: form input that handles edge cases\n\n```html\n\u003Cinput\n  type=\"email\"\n  name=\"email\"\n  maxlength=\"254\"      \u003C!-- RFC 5321 maximum email length -->\n  autocomplete=\"email\"\n  spellcheck=\"false\"\n  inputmode=\"email\"\n\u002F>\n```\n\n```js\n\u002F\u002F Validate beyond max-length\nfunction isValidEmail(value) {\n  if (!value || value.length > 254) return false;\n  if (!value.includes('@')) return false;\n  \u002F\u002F ... more validation\n  return true;\n}\n```\n\nThe `maxlength=\"254\"` is a margin: most emails are \u003C 30 characters, but the RFC allows up to 254. Designing for 254 absorbs the long tail without breaking.\n\n### Example 5: error budgets (Google SRE)\n\nGoogle's Site Reliability Engineering practice formalizes safety factors as \"error budgets\":\n\n- Service-level objective (SLO): 99.9% availability.\n- Error budget: 0.1% — about 43 minutes of downtime per month.\n- Engineering teams can spend the budget on risk: faster releases, infrastructure changes, experimental features.\n\nThe error budget is an explicit margin against perfection — and explicit guidance about when to slow down (budget consumed) and when to take risks (budget remaining).\n\n## Cross-domain examples\n\n### Bridges and structures\n\nCivil engineering's canonical safety-factor application. Bridges are designed for loads multiple times what they're rated to carry. Materials, weather, seismic events, and unanticipated use (heavy trucks, large crowds) are absorbed by the margin.\n\n### Aircraft\n\nAircraft use lower safety factors than buildings (1.5x rather than 5x) because weight matters and materials are highly engineered. The trade-off: extensive testing, redundant systems, and rigorous maintenance compensate for the slimmer margin.\n\n### Medical devices\n\nPharmaceutical dosing has built-in safety margins: the lethal dose of a drug is typically 10x or more of the therapeutic dose. The \"ignorance\" factor here is patient variation, drug interactions, and unusual conditions.\n\n### Disaster preparedness\n\nFEMA recommends households maintain 3 days of supplies (food, water, medicine). The 3-day window is a safety factor against typical disaster duration; communities maintain larger margins for less-typical disasters.\n\n### The Challenger disaster (the book's case)\n\nThe space shuttle Challenger O-rings were designed with a safety factor of 3 — meaning they could handle 3x the expected stress. In past launches, the actual safety factor (under varying temperatures) had eroded toward 1. On the cold morning of January 28, 1986, the O-rings failed at a temperature where the safety factor was estimated below 1. The decision to launch despite engineering objections cost seven lives.\n\nThe case illustrates a common pattern: when systems perform reliably over time, confidence rises and pressure to reduce safety factors (cost, schedule) accumulates. Lowering safety factors based on past success ignores that the past success was *partly* because of the safety factors.\n\n## Anti-patterns\n\n- **Optimizing without margin.** A system tuned to exactly its current load capacity. Any growth or spike crashes.\n- **Removing redundancy as \"waste.\"** Until the redundancy was needed, it looked unused. Then a single failure cascades.\n- **Designing for the typical case only.** Edge cases are encountered routinely; designing only for typical means routinely failing.\n- **Confidence eroding safety factors over time.** Systems that worked reliably get optimized for cost; the safety factor erodes; an unusual event causes failure.\n- **No graceful degradation.** Systems that crash hard on dependency failure, instead of degrading to limited functionality.\n- **Content limits that match typical content.** A name field allowing 30 characters works for most users; the user with a 35-character name has a broken account.\n\n## Heuristics\n\n1. **The \"what's the worst case?\" audit.** For each design decision, name the worst plausible case (longest content, highest load, lowest device capability). Does the design handle it?\n2. **The \"if this dependency fails\" check.** For each external dependency, ask: how does the system behave if this dependency fails? If the answer is \"the user sees a broken page,\" add margin.\n3. **The capacity headroom check.** What's the system's actual capacity vs. current peak load? Less than 2x is fragile; 5x+ is comfortable.\n4. **The \"we've never seen that before\" history.** Look at past incidents. Each one was probably \"unprecedented\" before it happened. New unprecedented things will happen.\n\n## Related principles\n\n- **`weakest-link`** — safety factors strengthen the chain; finding the weakest link is the first step.\n- **`scaling-fallacy`** — what works at small scale needs more margin at large scale.\n- **`structural-forms`** — the engineering analog: load-bearing patterns that distribute stress.\n- **`forgiveness`** — the user-side complement: designs that absorb user errors, not just system failures.\n- **`iteration`** — iterative testing helps identify where margin is needed.\n- **`uncertainty-principle`** — measurement itself introduces variability that the safety factor must absorb.\n\n## Sub-aspect skills\n\n- **`factor-of-safety-content-stress`** — designing UI to survive content extremes.\n- **`factor-of-safety-failure-margin`** — capacity planning, graceful degradation, redundancy.\n\n## Closing\n\nFactor of Safety is the engineering discipline that acknowledges what designers and builders try to forget: the unknown will arrive. Designs without margin fail loudly when it does; designs with margin absorb it. The cost of the margin is paid up front; the benefit pays out across the system's lifetime, especially in the moments no one anticipated.\n","# Factor of Safety\n\nFactor of Safety is the engineering practice of designing systems with capacity exceeding what's strictly required, to absorb unknown variations and prevent failure. A bridge rated for 5,000 lbs is built to hold 25,000 — a safety factor of 5. The \"extra\" capacity isn't waste; it's insurance against the things you didn't predict: corrosion, fatigue, unusual load combinations, materials that didn't quite meet spec.\n\nFor software design, the same logic applies: design with margin in performance, capacity, content handling, error tolerance, and edge cases. The unpredicted always shows up; the question is whether the system absorbs it gracefully or fails loudly.\n\n## Definition (in our own words)\n\nA factor of safety is the ratio of a system's actual capacity to the capacity it was designed to handle under normal use. The size of the factor depends on how much you don't know about the conditions the system will face — the more uncertainty, the larger the factor needs to be. The book's alternative name, \"factor of ignorance,\" is illuminating: a well-understood, well-tested system can have a small safety factor; a novel system facing unknown conditions needs a large one.\n\n## Origins and research lineage\n\n- **Engineering safety practice** going back centuries. The Pyramids of Giza, by some analyses, were over-engineered with safety factors of 20+ — the builders couldn't predict load conditions over millennia, so they built radically conservatively.\n- **Henry Petroski**, *To Engineer Is Human: The Role of Failure in Successful Design* (St. Martin's Press, 1985) and *Design Paradigms: Case Histories of Error and Judgment in Engineering* (Cambridge University Press, 1994). Petroski's central thesis: engineering progresses by understanding past failures, and safety factors are the explicit acknowledgment that the next failure will look like something not yet seen.\n- **Lidwell, Holden & Butler** (2003) compactly stated the principle and noted the inverse relationship between safety-factor size and design knowledge. The book's central case: the Challenger O-rings, designed for a safety factor of 3 in past launches but well below 3 at low temperatures.\n- **Modern reliability engineering** (Jens Rasmussen, Charles Perrow's *Normal Accidents*, James Reason's work on system failure) extends the idea to complex systems where multiple small margins compound into total system safety.\n- **Software practice** — capacity planning, redundancy, error budgets (Google SRE), graceful degradation — all are factor-of-safety in software vocabulary.\n\n## Why factor of safety matters\n\nEvery system designed at exactly its expected load will fail when it encounters more. Real systems always encounter more — through use you didn't predict, through growth, through abuse, through the long tail of edge cases. A system without margin fails loudly when conditions change; a system with margin absorbs the change gracefully and continues operating.\n\nThe cost of insufficient margin is well-documented:\n\n- **Performance**: a system sized for 1,000 users that hits 1,500 users degrades or crashes.\n- **Content**: a layout sized for 50-character names breaks when a user has a 90-character name.\n- **Network**: an API designed assuming 99.9% uptime fails when its dependency drops to 98%.\n- **Hardware**: a UI designed for 1080p screens looks broken on 4K and on small mobile.\n- **Cognitive**: a tool designed for the typical user fails for the user with motor impairment, low vision, or unfamiliarity.\n\nThe cost of *too much* margin is real too — over-engineering wastes resources, slows development, and can make systems harder to maintain. The discipline is calibrating margin to the actual uncertainty.\n\n## When to apply\n\n- **Performance and capacity planning.** Systems should run at meaningful headroom over typical load.\n- **Content handling.** Layouts must survive content that exceeds typical bounds — long names, big numbers, multi-line addresses, no images.\n- **Error tolerance.** Systems should fail gracefully on unexpected input rather than crashing.\n- **Network and dependency reliability.** Systems should degrade gracefully when dependencies are slow or down.\n- **Hardware variation.** UIs should work across device sizes, pixel densities, and input modalities.\n- **Accessibility.** Designs should accommodate users at the edges of typical capability ranges.\n- **Anywhere \"we've never seen that before\" is plausible.**\n\n## When NOT to over-apply\n\n- **Premature optimization.** Building 100x capacity when current load is 1x ties up resources better spent on other priorities.\n- **Speculative redundancy.** Multiple redundant systems for failure modes that have never occurred and aren't credible.\n- **Defensive code obscuring intent.** Wrapping every operation in try\u002Fcatch with no error-handling strategy. Doesn't help; obscures.\n\nThe right margin is enough to handle the credible unknown — not infinite.\n\n## How to size the safety factor\n\nThe book's insight: the safety factor should track the level of *ignorance* about the design parameters.\n\n- **Well-understood, well-tested system**: safety factor of 1.5–2x typical load.\n- **Moderately understood, some unknowns**: 2–4x.\n- **Novel system, significant unknowns**: 4–10x or more.\n- **Catastrophic-failure systems with severe consequence**: even higher.\n\nTypical safety factors in different engineering domains:\n\n- Steel structures: 2–3x.\n- Wood structures: 4–6x (more variable material).\n- Aircraft: 1.5x (highly engineered, weight-constrained — but with extensive other safety mechanisms).\n- Software capacity: highly variable, often 2–5x of expected peak load.\n- UI content: typically design for 1.5–2x the typical content length.\n\n## Worked examples\n\n### Example 1: layout that survives content extremes\n\nA user-card layout designed only for short names breaks for the user named \"María-José Esperanza Sánchez de Bermúdez.\"\n\n```css\n\u002F* Without margin *\u002F\n.user-name {\n  width: 200px;\n  white-space: nowrap;\n  overflow: hidden;\n}\n\u002F* Long names disappear into ellipsis silently *\u002F\n\n\u002F* With margin *\u002F\n.user-name {\n  max-width: 100%;\n  overflow-wrap: break-word;\n  hyphens: auto;\n}\n.user-card {\n  min-height: 80px;  \u002F* accommodates 1-3 lines *\u002F\n}\n```\n\nThe \"with margin\" version handles names from 5 to 90 characters; the layout grows gracefully.\n\n### Example 2: API capacity planning\n\nAn API expected to handle 100 requests\u002Fsecond is designed with capacity for 500 rps. Reasoning:\n\n- Marketing campaigns, viral growth, or app launches can spike traffic 5–10x.\n- Slow database queries can multiply effective load.\n- One client misbehaving can saturate the API for everyone.\n\nThe 5x margin handles common spikes; auto-scaling handles sustained growth beyond.\n\n### Example 3: graceful degradation when a dependency fails\n\n```js\nasync function fetchUserData(userId) {\n  try {\n    return await api.fetchUser(userId, { timeout: 2000 });\n  } catch (error) {\n    \u002F\u002F Graceful degradation: return cached data if available\n    const cached = await cache.get(`user:${userId}`);\n    if (cached) {\n      logger.warn('Using cached user data due to API failure', { userId, error });\n      return { ...cached, _stale: true };\n    }\n    \u002F\u002F Last resort: return minimal data so UI can render something\n    return { id: userId, name: 'Unknown', _placeholder: true };\n  }\n}\n```\n\nThree levels of margin: try the API; fall back to cache; fall back to placeholder. The UI never gets a hard crash from a transient failure.\n\n### Example 4: form input that handles edge cases\n\n```html\n\u003Cinput\n  type=\"email\"\n  name=\"email\"\n  maxlength=\"254\"      \u003C!-- RFC 5321 maximum email length -->\n  autocomplete=\"email\"\n  spellcheck=\"false\"\n  inputmode=\"email\"\n\u002F>\n```\n\n```js\n\u002F\u002F Validate beyond max-length\nfunction isValidEmail(value) {\n  if (!value || value.length > 254) return false;\n  if (!value.includes('@')) return false;\n  \u002F\u002F ... more validation\n  return true;\n}\n```\n\nThe `maxlength=\"254\"` is a margin: most emails are \u003C 30 characters, but the RFC allows up to 254. Designing for 254 absorbs the long tail without breaking.\n\n### Example 5: error budgets (Google SRE)\n\nGoogle's Site Reliability Engineering practice formalizes safety factors as \"error budgets\":\n\n- Service-level objective (SLO): 99.9% availability.\n- Error budget: 0.1% — about 43 minutes of downtime per month.\n- Engineering teams can spend the budget on risk: faster releases, infrastructure changes, experimental features.\n\nThe error budget is an explicit margin against perfection — and explicit guidance about when to slow down (budget consumed) and when to take risks (budget remaining).\n\n## Cross-domain examples\n\n### Bridges and structures\n\nCivil engineering's canonical safety-factor application. Bridges are designed for loads multiple times what they're rated to carry. Materials, weather, seismic events, and unanticipated use (heavy trucks, large crowds) are absorbed by the margin.\n\n### Aircraft\n\nAircraft use lower safety factors than buildings (1.5x rather than 5x) because weight matters and materials are highly engineered. The trade-off: extensive testing, redundant systems, and rigorous maintenance compensate for the slimmer margin.\n\n### Medical devices\n\nPharmaceutical dosing has built-in safety margins: the lethal dose of a drug is typically 10x or more of the therapeutic dose. The \"ignorance\" factor here is patient variation, drug interactions, and unusual conditions.\n\n### Disaster preparedness\n\nFEMA recommends households maintain 3 days of supplies (food, water, medicine). The 3-day window is a safety factor against typical disaster duration; communities maintain larger margins for less-typical disasters.\n\n### The Challenger disaster (the book's case)\n\nThe space shuttle Challenger O-rings were designed with a safety factor of 3 — meaning they could handle 3x the expected stress. In past launches, the actual safety factor (under varying temperatures) had eroded toward 1. On the cold morning of January 28, 1986, the O-rings failed at a temperature where the safety factor was estimated below 1. The decision to launch despite engineering objections cost seven lives.\n\nThe case illustrates a common pattern: when systems perform reliably over time, confidence rises and pressure to reduce safety factors (cost, schedule) accumulates. Lowering safety factors based on past success ignores that the past success was *partly* because of the safety factors.\n\n## Anti-patterns\n\n- **Optimizing without margin.** A system tuned to exactly its current load capacity. Any growth or spike crashes.\n- **Removing redundancy as \"waste.\"** Until the redundancy was needed, it looked unused. Then a single failure cascades.\n- **Designing for the typical case only.** Edge cases are encountered routinely; designing only for typical means routinely failing.\n- **Confidence eroding safety factors over time.** Systems that worked reliably get optimized for cost; the safety factor erodes; an unusual event causes failure.\n- **No graceful degradation.** Systems that crash hard on dependency failure, instead of degrading to limited functionality.\n- **Content limits that match typical content.** A name field allowing 30 characters works for most users; the user with a 35-character name has a broken account.\n\n## Heuristics\n\n1. **The \"what's the worst case?\" audit.** For each design decision, name the worst plausible case (longest content, highest load, lowest device capability). Does the design handle it?\n2. **The \"if this dependency fails\" check.** For each external dependency, ask: how does the system behave if this dependency fails? If the answer is \"the user sees a broken page,\" add margin.\n3. **The capacity headroom check.** What's the system's actual capacity vs. current peak load? Less than 2x is fragile; 5x+ is comfortable.\n4. **The \"we've never seen that before\" history.** Look at past incidents. Each one was probably \"unprecedented\" before it happened. New unprecedented things will happen.\n\n## Related principles\n\n- **`weakest-link`** — safety factors strengthen the chain; finding the weakest link is the first step.\n- **`scaling-fallacy`** — what works at small scale needs more margin at large scale.\n- **`structural-forms`** — the engineering analog: load-bearing patterns that distribute stress.\n- **`forgiveness`** — the user-side complement: designs that absorb user errors, not just system failures.\n- **`iteration`** — iterative testing helps identify where margin is needed.\n- **`uncertainty-principle`** — measurement itself introduces variability that the safety factor must absorb.\n\n## Sub-aspect skills\n\n- **`factor-of-safety-content-stress`** — designing UI to survive content extremes.\n- **`factor-of-safety-failure-margin`** — capacity planning, graceful degradation, redundancy.\n\n## Closing\n\nFactor of Safety is the engineering discipline that acknowledges what designers and builders try to forget: the unknown will arrive. Designs without margin fail loudly when it does; designs with margin absorb it. The cost of the margin is paid up front; the benefit pays out across the system's lifetime, especially in the moments no one anticipated.\n",{"name":5,"description":7},"main","b0f0a87593c578a7898eccaf1b363f7f87c1f99b","plugins\u002FHDeibler\u002Funiversal-design-principles\u002Fplugins\u002Fprocess-and-robustness-principles\u002Fskills\u002Ffactor-of-safety",483,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins","https:\u002F\u002Fhol.org\u002Fplugins\u002Fbest-codex-plugins","https:\u002F\u002Fgithub.com\u002Fhashgraph-online","https:\u002F\u002Fhol.org","Open-source standards and developer tools for interoperable AI agents: discovery, identity, communication, payments, privacy and security.","2026-11-13 02:16:32",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill factor-of-safety",{"tool":61,"command":62},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill factor-of-safety",{"tool":64,"command":65},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill factor-of-safety","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FHDeibler\u002Funiversal-design-principles\u002Fplugins\u002Fprocess-and-robustness-principles\u002Fskills\u002Ffactor-of-safety\u002FSKILL.md",true,[69],{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"references\u002Fpetroski-and-engineering-history.md","REFERENCE","参考文档",5905,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FHDeibler\u002Funiversal-design-principles\u002Fplugins\u002Fprocess-and-robustness-principles\u002Fskills\u002Ffactor-of-safety\u002Freferences\u002Fpetroski-and-engineering-history.md",[76,84,91,98,121,146],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":83},"01M746ZWACVKMZ1BJXJZHYJSSX","migrate-to-e2e","Moves an existing Playwright, Cypress, Selenium, Appium, Detox, Maestro, or TesterArmy suite to e2e one slice at a time, with the old suite running beside the new one until each ported test is proven. Keeps a MIGRATION.md progress file so any later session resumes where the last stopped. Optionally plants a defect to show both suites catch it. Use for \u002Fmigrate-to-e2e, \"migrate our tests to e2e\", \"port these Maestro flows\", \"move our TesterArmy tests\", or when a project has an e2e config and an older suite still running.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fmigrate-to-e2e\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":83},"01M746ZPTAX1Q0FBKAB1CYND7E","e2e","Writes, runs, and debugs end-to-end tests for web and mobile apps with e2e, the agentic test runner, which mixes agent.act goals with exact locator assertions on a Playwright browser or an iOS or Android device. Also drives a project's running app live over the e2e MCP server to look at a screen, check a UI change, take a screenshot or record a video, and try a locator; and runs bug bashes, parallel e2e explore runs with each bug proven by a repro test. Use when a project depends on e2e or has an e2e.config.ts, when asked for end-to-end, browser, mobile, or agentic UI tests, to check a change in the running app, to QA or bug bash an app or branch, or when an e2e run fails.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fe2e\u002FSKILL.md",[],[],{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":83},"01M746ZJN784HVHMDP9MQGCSGG","create-verification-skill","Generate a project-local verify-\u003Capp> skill on top of e2e, so any coding agent can launch the app, check it is worth driving, exercise a feature the way a user does, keep evidence, and bug bash it. Writes the skill, a feature map with one explore charter per feature, and proves it once. Use for \u002Fcreate-verification-skill, \"make a verification skill for this repo\", or when a project has no scripted way to prove UI behavior.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002FSKILL.md",[],[],{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":40},"01M716A6ETNB9B1SQ3GXZC75VR","deja-search","deja-vu memory — search the user's past AI coding sessions with the deja CLI. Holds what they already settled and never wrote into the repo (naming rules, banned or already-tried tools, required checks before merge, preferred values, who owns what). Use before your first edit in a task, before you call a change done or ready to merge, before you recommend a tool, library, design or reviewer, before re-debugging an error that may already be solved, when they say 'didn't we fix this before', 'what did we decide about X' or 'I already have that', and before telling them something on this machine does not exist.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-search\u002FSKILL.md",[],[105,106,107,27,108,109,110,111,112,31,113,23,26,114,115,116,117,118,119,120],"search","deja search","never","ready","memory","re","decide","fix","debugging","done","reviewer","io","change","cli","merge","past",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":127,"publishedAt":40},"01M716A3J2W5SENSE9VGMXB375","deja-reflect","End-of-session reflection and memory curation with deja-vu. Review what was decided, what commands broke and what repaired them, and record durable project rules or decisions with deja remember so the next session starts with them.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-reflect\u002FSKILL.md",[],[128,129,130,116,131,132,133,134,135,136,137,138,139,140,109,141,142,143,144,145],"deja reflect","reflect","review","with","record","github","next","https","node","Rules","decisions","brew","remember","project rules","project","session","end","reflection",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":163,"publishedAt":40},"01M715T3RR4BAYSR57HPPTJ0PF","revid","Make, edit, export and post AI videos with Revid (revid.ai) through the Revid MCP server. Use whenever the user wants a short-form or long-form video made (from an idea, a script, a URL, an article, a PDF, a tweet, a product page, their own clips, or a song), wants to find what is going viral on TikTok, YouTube, Instagram or X before making something, wants to edit or re-export an existing Revid project, generate a standalone AI image or clip, make a series episode, or publish and schedule a finished video to connected social accounts. Covers setup (hosted MCP with OAuth, or an API key), the 36 tools, credits, polling and the rules for publishing. Routes to the more specific revid-* skills when one fits.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftmakersas\u002Frevid-skills\u002Fskills\u002Frevid\u002FSKILL.md",[152,157,160],{"categoryNo":153,"categoryName":154,"taxonomyType":155,"taxonomyTypeDesc":156},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",{"categoryNo":158,"categoryName":159,"taxonomyType":155,"taxonomyTypeDesc":156},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":161,"categoryName":162,"taxonomyType":155,"taxonomyTypeDesc":156},"01JBSEEDCAT000000000000010","后端与接口",[148,164,165,166,167,168,169,142,170,110,171,172,173,174,23,175,176,177,178,179],"URL","Video","short-form","standalone","PDF","viral","tiktok","short","social","MCP","song","image","mcp server","schedule","api","publish"]