[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CF6PX2H1M2M22GP2YKHBEF":3,"skill-same:01M6CF6PX2H1M2M22GP2YKHBEF":61},{"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":29,"linkOnly":30,"markdownContent":31,"markdownBody":32,"frontMatter":33,"refName":39,"commitSha":40,"skillDirectory":41,"forksCount":42,"repositoryHtmlUrl":43,"repositoryHomepageUrl":6,"ownerHtmlUrl":44,"ownerBlogUrl":6,"ownerDescription":45,"updatedAt":46,"install":47,"resources":60},"01M6CF6PX2H1M2M22GP2YKHBEF","performance-reliability",null,"Model cost, saturation, failure, and degradation before the system surprises you in production.","usurobor\u002Fcnos","usurobor","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F182342826?v=4","01M6CEXJCRMYD8HB2315FGB1Q8","Peter Lisovin","01M6CEXJH2RW04GQ2SNXY40F5S",9,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.eng\u002Fskills\u002Feng\u002Fperformance-reliability\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28],"performance","reliability","performance reliability","uptime","Production","how","system","model","saturation","cost","2026-11-10 10:12:30",false,"---\nname: performance-reliability\ndescription: Model cost, saturation, failure, and degradation before the system surprises you in production.\ngoverning_question: How do we make performance and failure budgets visible before the system enforces them for us?\ntriggers: [performance, reliability, latency, throughput, uptime]\nscope: task-local\n---\n\n# Performance & Reliability\n\nModel cost, saturation, failure, and degradation before the system surprises you in production.\n\n## Core Principle\n\n**Coherent performance and reliability work starts from budgets, saturation points, and recovery boundaries — not from vague hopes that the system is “fast enough” or “robust enough.”**\n\nA good performance\u002Freliability design does at least one of these:\n\n- names the steady-state cost model\n- identifies amplification and saturation paths\n- defines budgets and limits explicitly\n- makes degradation behavior intentional\n- proves failure and recovery paths are bounded and observable\n\nCorrectness is necessary.  \nFor operational systems, it is not sufficient.\n\n---\n\n## 1. Define\n\n### 1.1. Identify the parts\n\nEvery performance\u002Freliability problem has these parts:\n\n- **Workload** — what the system is asked to do\n- **Resource** — CPU, memory, disk, network, queue slots, operator attention, wall-clock time\n- **Budget** — the explicit limit for that resource\n- **Amplification path** — where one input can cause disproportionately more work\n- **Failure mode** — how the system degrades or breaks\n- **Recovery path** — how it returns to a coherent state\n- **Evidence** — traces, projections, tests, measurements\n\n- ❌ \"This should be fast\"\n- ✅ \"This path makes one LLM call per pass, bounded to max_passes = 5, with total artifact bytes capped\"\n\n### 1.2. Articulate how they fit\n\nPerformance and reliability are coherent when:\n\n- the workload is named\n- the budgets are explicit\n- the amplification paths are visible\n- the failure mode is bounded\n- the recovery path is deliberate\n- the operator can tell what state the system is in\n\n- ❌ \"Retries make it robust\"\n- ✅ \"Retries are capped at 3, then dead-letter, with explicit trace events and offset advancement\"\n\n### 1.3. Name the failure mode\n\nPerformance\u002Freliability work fails through **implicitness**:\n- cost exists but is not named\n- limits exist but are not surfaced\n- retries exist but are not bounded\n- overload exists but has no degradation mode\n- recovery exists but cannot be observed\n\n- ❌ \"It times out sometimes\"\n- ✅ \"The extension host has no timeout budget and can block the pass loop indefinitely\"\n\n---\n\n## 2. Unfold\n\n### 2.1. Start from workload, not implementation\n\nName the workload first.\n\nExamples:\n- one Telegram message through the full daemon cycle\n- one N-pass loop under max passes\n- one extension host request\n- one registry refresh\n- one `cn sync` round-trip\n- one bundle install\u002Fupdate\u002Frollback\n\n- ❌ \"Optimize this module\"\n- ✅ \"Model the cost of one full message-processing cycle under typical and worst-case inputs\"\n\n### 2.2. Write the steady-state cost model\n\nFor the normal path, state:\n\n- how many calls \u002F passes \u002F subprocesses \u002F IO operations happen\n- what grows with input size\n- what is constant\n- what is bounded by config\n- what is cached\n\nA simple structured form is enough:\n\n- **CPU**\n- **memory**\n- **disk**\n- **network**\n- **latency**\n- **operator-facing delay**\n\n- ❌ \"This is lightweight\"\n- ✅ \"One extension op = one subprocess RPC with timeout ≤ 30s and max_bytes ≤ 64 KiB\"\n\n### 2.3. Name the budgets explicitly\n\nEvery meaningful resource path should have a named budget.\n\nTypical budgets:\n- timeout\n- max passes\n- max retries\n- max artifact bytes\n- max total ops\n- queue depth\n- batch size\n- refresh interval\n- health-check interval\n\n- ❌ \"We should avoid large payloads\"\n- ✅ \"Artifact bytes are capped at 131072 total and 16384 per op\"\n\n### 2.4. Find amplification paths\n\nAsk:\n- where can one input create many outputs?\n- where can one failure cause repeated retries?\n- where can one message trigger unbounded follow-on work?\n- where can one large payload multiply memory or disk use?\n\nCommon amplification sites:\n- retries\n- fan-out messaging\n- extension host spawning\n- repeated scans \u002F discovery\n- N-pass loops\n- registry refresh + install resolution\n- trace\u002Fevent emission\n\n- ❌ Ignore amplification until it causes incidents\n- ✅ \"One bad Telegram update can reappear forever unless offset advances or dead-lettering happens\"\n\n### 2.5. Distinguish graceful degradation from failure\n\nFor each overload or error path, decide:\n\n- what should continue\n- what should stop\n- what should degrade\n- what should be skipped\n- what should dead-letter\n- what should become `degraded` in readiness\n\n- ❌ \"If this fails, everything errors\"\n- ✅ \"If extension health check fails, disable the extension and keep the runtime alive\"\n\n### 2.6. Make recovery a first-class design surface\n\nFor each failure mode, define:\n\n- what state is persisted\n- what is retried\n- what is idempotent\n- what gets quarantined\n- what gets dead-lettered\n- what the operator sees\n\n- ❌ \"We can rerun it\"\n- ✅ \"Trigger retries are capped at 3; after that the update is dead-lettered and the offset is advanced\"\n\n### 2.7. Surface operational truth to the operator\n\nIf a system degrades, the operator should be able to tell:\n\n- what is healthy\n- what is disabled\n- what is saturated\n- what is retrying\n- what is dead-lettered\n- what is blocked\n- what budget was exceeded\n\nUse:\n- runtime projections\n- readiness state\n- doctor\n- traceability events\n- receipts\u002Fartifacts\n\n- ❌ \"It’s slower\"\n- ✅ \"`ready.json` shows degraded; `runtime.json` shows current_pass and queue depth; trace shows `budget_exhausted`\"\n\n### 2.8. Prefer bounded loops over optimistic loops\n\nIf a process can repeat, bound it explicitly.\n\nExamples:\n- N-pass loop\n- retries\n- backoff cycles\n- health checks\n- queue drains\n- sync tick loops\n\n- ❌ \"Loop until done\"\n- ✅ \"Drain until queue empty, lock busy, processing failed, or drain limit reached\"\n\n### 2.9. Make time part of the design\n\nWhen time matters, specify:\n\n- timeout\n- retry spacing\n- refresh interval\n- scheduling interval\n- staleness threshold\n- overdue threshold\n\n- ❌ \"Review runs periodically\"\n- ✅ \"`review_interval_sec` gates review tick by wall-clock elapsed time\"\n\n### 2.10. Model the worst-case path, not just the happy path\n\nFor every subsystem, ask:\n\n- what is the worst valid input?\n- what is the worst invalid input?\n- what happens if every retry is consumed?\n- what happens if the peer is unreachable?\n- what happens if the extension host hangs?\n- what happens if CI\u002Fbuild fails during release?\n\n- ❌ \"Typical case is fine\"\n- ✅ \"Worst-case extension request times out, emits `extension.op.error`, and leaves the runtime alive\"\n\n### 2.11. Require one explicit saturation story\n\nEach substantial subsystem should answer:\n\n> **How does this saturate, and what happens then?**\n\nExamples:\n- queue fills\n- retries exhausted\n- bytes exceeded\n- passes exhausted\n- network unavailable\n- registry unavailable\n- extension disabled\n\n- ❌ No saturation plan\n- ✅ \"At retry exhaustion, dead-letter and advance offset; do not poison the daemon loop\"\n\n### 2.12. Tie performance to architecture decisions\n\nPerformance\u002Freliability is not a postscript.\nIt should affect architecture choices such as:\n\n- core vs extension\n- subprocess vs native\n- local vs remote\n- eager vs lazy loading\n- built-in vs package-installed\n- sync vs async delivery\n\n- ❌ \"We’ll benchmark later\"\n- ✅ \"Subprocess host is chosen because failure isolation matters more than raw speed for risky extensions\"\n\n### 2.13. Test the budgets and failure paths\n\nPerformance\u002Freliability design is incomplete without tests for:\n\n- budget exhaustion\n- retries\u002Fdead-letter\n- timeout\n- disabled states\n- degraded readiness\n- queue stop reasons\n- host health failures\n- recovery path\n\n- ❌ Test only success\n- ✅ Test timeout, retry exhaustion, and graceful disablement\n\n### 2.14. Keep the proof proportional\n\nYou do not need a load lab for every change.\nBut you do need evidence proportional to the claim.\n\nExamples:\n- unit test for timeout classifier\n- integration test for queue stop reasons\n- artifact\u002Fprojection test for degraded readiness\n- benchmark or measurement only when making performance claims\n\n- ❌ \"It should scale\"\n- ✅ \"This is bounded by max_passes and max_total_ops; no separate benchmark claim is made\"\n\n---\n\n## 3. Rules\n\n### 3.1. Start with a workload\nDo not discuss performance in the abstract.\n\n- ❌ \"Make runtime faster\"\n- ✅ \"Model one Telegram message through booted daemon processing\"\n\n### 3.2. Every repeated path gets a bound\nIf it can loop, retry, poll, or fan out, it gets a bound.\n\n- ❌ Infinite optimism\n- ✅ Explicit max retries \u002F max passes \u002F max bytes \u002F drain limits\n\n### 3.3. Every budget must be named\nUnnamed limits are wishful thinking.\n\n- ❌ \"Small payload\"\n- ✅ \"64 KiB max response body\"\n\n### 3.4. Failure must be cheaper than collapse\nWhen things go wrong, the system should degrade, skip, dead-letter, disable, or quarantine — not amplify.\n\n- ❌ One bad update poisons the daemon forever\n- ✅ One bad update is dead-lettered and the loop continues\n\n### 3.5. Operator truth is part of the design\nIf the operator cannot tell what failed or degraded, the reliability model is incomplete.\n\n- ❌ Silent disablement\n- ✅ `extension.disabled`, `budget_exhausted`, `dead_lettered`, degraded readiness\n\n### 3.6. Recovery must be explicit\nDo not assume restart = recovery.\n\n- ❌ \"It will recover on next run\"\n- ✅ \"State is persisted; replay or dead-letter behavior is specified\"\n\n### 3.7. Amplification paths must be called out\nName where one input can create disproportionate work.\n\n- ❌ Ignore retry fan-out\n- ✅ \"Each failed update can trigger at most 3 retries, then dead-letter\"\n\n### 3.8. Saturation behavior is part of correctness\nA system that works only under low load is not fully correct operationally.\n\n- ❌ \"Works in dev\"\n- ✅ \"At queue saturation, drain limit stops work and state remains truthful\"\n\n### 3.9. Choose architecture with cost in mind\nPerformance\u002Freliability should shape architecture, not merely validate it after the fact.\n\n- ❌ Choose same-process plugin loading only for elegance\n- ✅ Choose subprocess host because failure isolation is more valuable than lower overhead here\n\n### 3.10. Prefer deterministic degradation\nBounded, named, repeatable failure is better than occasional lucky success.\n\n- ❌ Flaky retries\n- ✅ Capped retries + dead-letter + trace event\n\n### 3.11. Do not overclaim\nIf you did not measure or prove a performance property, do not claim it.\n\n- ❌ \"Scales well\"\n- ✅ \"Bounded by these budgets; no throughput claim made\"\n\n### 3.12. Use the smallest complete reliability proof\nDo not invent a benchmarking burden for every change.\nBut do prove the critical bounds and failure modes.\n\n- ❌ Benchmark everything\n- ✅ Test the boundedness and correctness of the overload path\n\n---\n\n## 4. Output Pattern\n\nA strong performance\u002Freliability section should contain at least:\n\n1. **Workload**\n2. **Budgets**\n3. **Steady-state cost model**\n4. **Amplification paths**\n5. **Failure modes**\n6. **Degradation behavior**\n7. **Recovery**\n8. **Operator-visible evidence**\n9. **Known gaps**\n\n### Example shape\n\n```markdown\n## Workload\nOne extension-backed HTTP observe request during an N-pass cycle.\n\n## Budgets\n- timeout: 30s\n- max_bytes: 64 KiB\n- max_passes: 5\n\n## Steady-state cost model\n- one subprocess RPC\n- one trace start event\n- one trace end event\n- one artifact write on success\n\n## Amplification paths\n- repeated retries if host is unhealthy\n- repeated pass continuation if effects defer\n\n## Failure modes\n- host timeout\n- invalid manifest\n- disabled extension\n- policy rejection\n\n## Degradation behavior\n- timeout => error receipt, runtime continues\n- unhealthy host => extension disabled, runtime degraded but alive\n\n## Recovery\n- host may be retried on later health check\n- disabled state visible to doctor and runtime contract\n\n## Operator-visible evidence\n- `extension.health.error`\n- `extension.disabled`\n- degraded readiness\n\n## Known gaps\n- no throughput benchmark yet","# Performance & Reliability\n\nModel cost, saturation, failure, and degradation before the system surprises you in production.\n\n## Core Principle\n\n**Coherent performance and reliability work starts from budgets, saturation points, and recovery boundaries — not from vague hopes that the system is “fast enough” or “robust enough.”**\n\nA good performance\u002Freliability design does at least one of these:\n\n- names the steady-state cost model\n- identifies amplification and saturation paths\n- defines budgets and limits explicitly\n- makes degradation behavior intentional\n- proves failure and recovery paths are bounded and observable\n\nCorrectness is necessary.  \nFor operational systems, it is not sufficient.\n\n---\n\n## 1. Define\n\n### 1.1. Identify the parts\n\nEvery performance\u002Freliability problem has these parts:\n\n- **Workload** — what the system is asked to do\n- **Resource** — CPU, memory, disk, network, queue slots, operator attention, wall-clock time\n- **Budget** — the explicit limit for that resource\n- **Amplification path** — where one input can cause disproportionately more work\n- **Failure mode** — how the system degrades or breaks\n- **Recovery path** — how it returns to a coherent state\n- **Evidence** — traces, projections, tests, measurements\n\n- ❌ \"This should be fast\"\n- ✅ \"This path makes one LLM call per pass, bounded to max_passes = 5, with total artifact bytes capped\"\n\n### 1.2. Articulate how they fit\n\nPerformance and reliability are coherent when:\n\n- the workload is named\n- the budgets are explicit\n- the amplification paths are visible\n- the failure mode is bounded\n- the recovery path is deliberate\n- the operator can tell what state the system is in\n\n- ❌ \"Retries make it robust\"\n- ✅ \"Retries are capped at 3, then dead-letter, with explicit trace events and offset advancement\"\n\n### 1.3. Name the failure mode\n\nPerformance\u002Freliability work fails through **implicitness**:\n- cost exists but is not named\n- limits exist but are not surfaced\n- retries exist but are not bounded\n- overload exists but has no degradation mode\n- recovery exists but cannot be observed\n\n- ❌ \"It times out sometimes\"\n- ✅ \"The extension host has no timeout budget and can block the pass loop indefinitely\"\n\n---\n\n## 2. Unfold\n\n### 2.1. Start from workload, not implementation\n\nName the workload first.\n\nExamples:\n- one Telegram message through the full daemon cycle\n- one N-pass loop under max passes\n- one extension host request\n- one registry refresh\n- one `cn sync` round-trip\n- one bundle install\u002Fupdate\u002Frollback\n\n- ❌ \"Optimize this module\"\n- ✅ \"Model the cost of one full message-processing cycle under typical and worst-case inputs\"\n\n### 2.2. Write the steady-state cost model\n\nFor the normal path, state:\n\n- how many calls \u002F passes \u002F subprocesses \u002F IO operations happen\n- what grows with input size\n- what is constant\n- what is bounded by config\n- what is cached\n\nA simple structured form is enough:\n\n- **CPU**\n- **memory**\n- **disk**\n- **network**\n- **latency**\n- **operator-facing delay**\n\n- ❌ \"This is lightweight\"\n- ✅ \"One extension op = one subprocess RPC with timeout ≤ 30s and max_bytes ≤ 64 KiB\"\n\n### 2.3. Name the budgets explicitly\n\nEvery meaningful resource path should have a named budget.\n\nTypical budgets:\n- timeout\n- max passes\n- max retries\n- max artifact bytes\n- max total ops\n- queue depth\n- batch size\n- refresh interval\n- health-check interval\n\n- ❌ \"We should avoid large payloads\"\n- ✅ \"Artifact bytes are capped at 131072 total and 16384 per op\"\n\n### 2.4. Find amplification paths\n\nAsk:\n- where can one input create many outputs?\n- where can one failure cause repeated retries?\n- where can one message trigger unbounded follow-on work?\n- where can one large payload multiply memory or disk use?\n\nCommon amplification sites:\n- retries\n- fan-out messaging\n- extension host spawning\n- repeated scans \u002F discovery\n- N-pass loops\n- registry refresh + install resolution\n- trace\u002Fevent emission\n\n- ❌ Ignore amplification until it causes incidents\n- ✅ \"One bad Telegram update can reappear forever unless offset advances or dead-lettering happens\"\n\n### 2.5. Distinguish graceful degradation from failure\n\nFor each overload or error path, decide:\n\n- what should continue\n- what should stop\n- what should degrade\n- what should be skipped\n- what should dead-letter\n- what should become `degraded` in readiness\n\n- ❌ \"If this fails, everything errors\"\n- ✅ \"If extension health check fails, disable the extension and keep the runtime alive\"\n\n### 2.6. Make recovery a first-class design surface\n\nFor each failure mode, define:\n\n- what state is persisted\n- what is retried\n- what is idempotent\n- what gets quarantined\n- what gets dead-lettered\n- what the operator sees\n\n- ❌ \"We can rerun it\"\n- ✅ \"Trigger retries are capped at 3; after that the update is dead-lettered and the offset is advanced\"\n\n### 2.7. Surface operational truth to the operator\n\nIf a system degrades, the operator should be able to tell:\n\n- what is healthy\n- what is disabled\n- what is saturated\n- what is retrying\n- what is dead-lettered\n- what is blocked\n- what budget was exceeded\n\nUse:\n- runtime projections\n- readiness state\n- doctor\n- traceability events\n- receipts\u002Fartifacts\n\n- ❌ \"It’s slower\"\n- ✅ \"`ready.json` shows degraded; `runtime.json` shows current_pass and queue depth; trace shows `budget_exhausted`\"\n\n### 2.8. Prefer bounded loops over optimistic loops\n\nIf a process can repeat, bound it explicitly.\n\nExamples:\n- N-pass loop\n- retries\n- backoff cycles\n- health checks\n- queue drains\n- sync tick loops\n\n- ❌ \"Loop until done\"\n- ✅ \"Drain until queue empty, lock busy, processing failed, or drain limit reached\"\n\n### 2.9. Make time part of the design\n\nWhen time matters, specify:\n\n- timeout\n- retry spacing\n- refresh interval\n- scheduling interval\n- staleness threshold\n- overdue threshold\n\n- ❌ \"Review runs periodically\"\n- ✅ \"`review_interval_sec` gates review tick by wall-clock elapsed time\"\n\n### 2.10. Model the worst-case path, not just the happy path\n\nFor every subsystem, ask:\n\n- what is the worst valid input?\n- what is the worst invalid input?\n- what happens if every retry is consumed?\n- what happens if the peer is unreachable?\n- what happens if the extension host hangs?\n- what happens if CI\u002Fbuild fails during release?\n\n- ❌ \"Typical case is fine\"\n- ✅ \"Worst-case extension request times out, emits `extension.op.error`, and leaves the runtime alive\"\n\n### 2.11. Require one explicit saturation story\n\nEach substantial subsystem should answer:\n\n> **How does this saturate, and what happens then?**\n\nExamples:\n- queue fills\n- retries exhausted\n- bytes exceeded\n- passes exhausted\n- network unavailable\n- registry unavailable\n- extension disabled\n\n- ❌ No saturation plan\n- ✅ \"At retry exhaustion, dead-letter and advance offset; do not poison the daemon loop\"\n\n### 2.12. Tie performance to architecture decisions\n\nPerformance\u002Freliability is not a postscript.\nIt should affect architecture choices such as:\n\n- core vs extension\n- subprocess vs native\n- local vs remote\n- eager vs lazy loading\n- built-in vs package-installed\n- sync vs async delivery\n\n- ❌ \"We’ll benchmark later\"\n- ✅ \"Subprocess host is chosen because failure isolation matters more than raw speed for risky extensions\"\n\n### 2.13. Test the budgets and failure paths\n\nPerformance\u002Freliability design is incomplete without tests for:\n\n- budget exhaustion\n- retries\u002Fdead-letter\n- timeout\n- disabled states\n- degraded readiness\n- queue stop reasons\n- host health failures\n- recovery path\n\n- ❌ Test only success\n- ✅ Test timeout, retry exhaustion, and graceful disablement\n\n### 2.14. Keep the proof proportional\n\nYou do not need a load lab for every change.\nBut you do need evidence proportional to the claim.\n\nExamples:\n- unit test for timeout classifier\n- integration test for queue stop reasons\n- artifact\u002Fprojection test for degraded readiness\n- benchmark or measurement only when making performance claims\n\n- ❌ \"It should scale\"\n- ✅ \"This is bounded by max_passes and max_total_ops; no separate benchmark claim is made\"\n\n---\n\n## 3. Rules\n\n### 3.1. Start with a workload\nDo not discuss performance in the abstract.\n\n- ❌ \"Make runtime faster\"\n- ✅ \"Model one Telegram message through booted daemon processing\"\n\n### 3.2. Every repeated path gets a bound\nIf it can loop, retry, poll, or fan out, it gets a bound.\n\n- ❌ Infinite optimism\n- ✅ Explicit max retries \u002F max passes \u002F max bytes \u002F drain limits\n\n### 3.3. Every budget must be named\nUnnamed limits are wishful thinking.\n\n- ❌ \"Small payload\"\n- ✅ \"64 KiB max response body\"\n\n### 3.4. Failure must be cheaper than collapse\nWhen things go wrong, the system should degrade, skip, dead-letter, disable, or quarantine — not amplify.\n\n- ❌ One bad update poisons the daemon forever\n- ✅ One bad update is dead-lettered and the loop continues\n\n### 3.5. Operator truth is part of the design\nIf the operator cannot tell what failed or degraded, the reliability model is incomplete.\n\n- ❌ Silent disablement\n- ✅ `extension.disabled`, `budget_exhausted`, `dead_lettered`, degraded readiness\n\n### 3.6. Recovery must be explicit\nDo not assume restart = recovery.\n\n- ❌ \"It will recover on next run\"\n- ✅ \"State is persisted; replay or dead-letter behavior is specified\"\n\n### 3.7. Amplification paths must be called out\nName where one input can create disproportionate work.\n\n- ❌ Ignore retry fan-out\n- ✅ \"Each failed update can trigger at most 3 retries, then dead-letter\"\n\n### 3.8. Saturation behavior is part of correctness\nA system that works only under low load is not fully correct operationally.\n\n- ❌ \"Works in dev\"\n- ✅ \"At queue saturation, drain limit stops work and state remains truthful\"\n\n### 3.9. Choose architecture with cost in mind\nPerformance\u002Freliability should shape architecture, not merely validate it after the fact.\n\n- ❌ Choose same-process plugin loading only for elegance\n- ✅ Choose subprocess host because failure isolation is more valuable than lower overhead here\n\n### 3.10. Prefer deterministic degradation\nBounded, named, repeatable failure is better than occasional lucky success.\n\n- ❌ Flaky retries\n- ✅ Capped retries + dead-letter + trace event\n\n### 3.11. Do not overclaim\nIf you did not measure or prove a performance property, do not claim it.\n\n- ❌ \"Scales well\"\n- ✅ \"Bounded by these budgets; no throughput claim made\"\n\n### 3.12. Use the smallest complete reliability proof\nDo not invent a benchmarking burden for every change.\nBut do prove the critical bounds and failure modes.\n\n- ❌ Benchmark everything\n- ✅ Test the boundedness and correctness of the overload path\n\n---\n\n## 4. Output Pattern\n\nA strong performance\u002Freliability section should contain at least:\n\n1. **Workload**\n2. **Budgets**\n3. **Steady-state cost model**\n4. **Amplification paths**\n5. **Failure modes**\n6. **Degradation behavior**\n7. **Recovery**\n8. **Operator-visible evidence**\n9. **Known gaps**\n\n### Example shape\n\n```markdown\n## Workload\nOne extension-backed HTTP observe request during an N-pass cycle.\n\n## Budgets\n- timeout: 30s\n- max_bytes: 64 KiB\n- max_passes: 5\n\n## Steady-state cost model\n- one subprocess RPC\n- one trace start event\n- one trace end event\n- one artifact write on success\n\n## Amplification paths\n- repeated retries if host is unhealthy\n- repeated pass continuation if effects defer\n\n## Failure modes\n- host timeout\n- invalid manifest\n- disabled extension\n- policy rejection\n\n## Degradation behavior\n- timeout => error receipt, runtime continues\n- unhealthy host => extension disabled, runtime degraded but alive\n\n## Recovery\n- host may be retried on later health check\n- disabled state visible to doctor and runtime contract\n\n## Operator-visible evidence\n- `extension.health.error`\n- `extension.disabled`\n- degraded readiness\n\n## Known gaps\n- no throughput benchmark yet",{"name":5,"scope":34,"triggers":35,"description":7,"governing_question":38},"task-local",[19,20,36,37,22],"latency","throughput","How do we make performance and failure budgets visible before the system enforces them for us?","main","fb527e6c4bfb75c71fa75d6471b3aa3da32106d4","src\u002Fpackages\u002Fcnos.eng\u002Fskills\u002Feng\u002Fperformance-reliability",0,"https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos","https:\u002F\u002Fgithub.com\u002Fusurobor","Coherence engineer. Building git-CN.","2026-11-07 14:25:44",{"source":8,"skillName":5,"commands":48,"prompt":58,"zipAvailable":59},[49,52,55],{"tool":50,"command":51},"npx","npx skills add usurobor\u002Fcnos --skill performance-reliability",{"tool":53,"command":54},"bunx","bunx skills add usurobor\u002Fcnos --skill performance-reliability",{"tool":56,"command":57},"pnpm","pnpm dlx skills add usurobor\u002Fcnos --skill performance-reliability","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.eng\u002Fskills\u002Feng\u002Fperformance-reliability\u002FSKILL.md",true,[],[62,80,96,124,141,162],{"skillNo":63,"name":64,"nameZh":6,"description":65,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":68,"publishedAt":29},"01M6CF8RWQPM0VXZG06XMR0FFX","issues\u002Ftriage","Issue triage doctrine pointer. Use when classifying a new issue, deciding dispatch eligibility, or deciding whether to close\u002Fsupersede\u002Fdefer.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.issues\u002Fskills\u002Ftriage\u002FSKILL.md",[],[69,70,71,72,73,24,74,75,76,77,78,79],"triage","issues","issues triage","issue triage","SET","decision","public","use","dispatch","issue","doctrine",{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":29},"01M6CF8PJ812DD4APZ3WE8X67B","issues\u002Ftaxonomy","Issue label taxonomy pointer. Use when classifying an issue's kind\u002Farea\u002Fpriority\u002Feffort\u002Fstatus\u002Fprotocol\u002Fdispatch labels, or when the board needs to interpret them.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.issues\u002Fskills\u002Ftaxonomy\u002FSKILL.md",[],[70,87,88,89,90,91,73,92,75,93,76,77,94,78,95],"taxonomy","issues taxonomy","github","status","protocol","open","board","github issue","issue labels",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":112,"publishedAt":29},"01M6CF8KBMZ4D0CDJQ3PF1YVTP","issues\u002Fmap","Issue-board (Issue Pivot) generation domain. Use when reasoning about `cn issues map`'s fetch, taxonomy-parse, effort-computation, and render pipeline, or about the board's JSON\u002FHTML output contract.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.issues\u002Fskills\u002Fmap\u002FSKILL.md",[102,107],{"categoryNo":103,"categoryName":104,"taxonomyType":105,"taxonomyTypeDesc":106},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":108,"categoryName":109,"taxonomyType":110,"taxonomyTypeDesc":111},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[70,113,89,114,115,116,73,117,87,92,24,118,119,93,120,121,122,123,76,78],"issues map","reasoning","data","pipeline","api","json","README","edit","interactive","fetch","generated",{"skillNo":125,"name":70,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":129,"publishedAt":29},"01M6CF8CZQH7G7B7RZPANQWR4G","cnos.issues package entrypoint. Use when reasoning about issue taxonomy, the Issue Pivot \u002F issue-board (`cn issues map`), the read-only CDS issue-state evaluator (`cn issues fsm evaluate`), or the current command-dispatch disposition of issue tooling.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.issues\u002FSKILL.md",[],[70,89,130,131,132,133,134,135,136,87,92,24,74,137,119,138,76,139,77,140],"pr","current state","run","artifacts","state","package","boundary","branch","command","only","cds",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":147,"publishedAt":29},"01M6CF896XKSRQVB1CSHY8GSXB","receipt-stream","Cross-cycle receipt-stream doctrine for protocol-iteration. Use when γ closes a cycle and writes the per-cycle iteration artifact (`cdd-iteration.md`), when γ updates the cross-cycle aggregator at `.cdd\u002Fiterations\u002FINDEX.md`, when ε reads the receipt stream across cycles to surface protocol-gap patterns, when a finding's disposition lands a cross-repo patch and the cross-repo trace bundle attaches, or when a courtesy empty-findings stub is written for a `protocol_gap_count == 0` cycle.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.handoff\u002Fskills\u002Fhandoff\u002Freceipt-stream\u002FSKILL.md",[],[148,149,133,91,150,24,151,152,153,75,154,155,156,157,76,158,159,160,161,79],"receipt stream","handoff","index","learning","format","trace","repo","closeout","read","channel","embedded","patch","shape","cdd",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":168,"publishedAt":29},"01M6CF84VCBME6RK8V6HAVDM8Z","mid-flight","Mid-flight γ→in-flight-α rescue channel. Use when γ needs to change a load-bearing fact (pinned axis, scope, AC, blocker) after α has begun coding, when γ edits the cycle's GitHub issue body mid-cycle, or when a spec change lands on origin\u002Fmain while α\u002Fβ polling sessions are in-flight.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.handoff\u002Fskills\u002Fhandoff\u002Fmid-flight\u002FSKILL.md",[],[169,89,170,171,172,173,24,174,175,137,154,156,76,139,77,176,94,177,178,179],"mid flight","change","sessions","file","cache","pin","coordination","up","Legacy","gamma","artifact channel"]