{"id":"5f994fc6-a04d-4d73-80e9-63b74ca1e468","entityType":"agent","slug":"clawhub-1231111-software-architecture-design","name":"Software Architecture Design SOP","canonicalUrl":"https://www.xpersona.co/agent/clawhub-1231111-software-architecture-design","canonicalPath":"/agent/clawhub-1231111-software-architecture-design","generatedAt":"2026-10-11T10:51:16.047Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-11T07:07:53.517Z","emptyReason":null},"description":"Produces a complete software architecture design document following a 12-phase SOP. Supports web backend, mobile, ML/AI, data pipeline, embedded/IoT. Generat... Skill: Software Architecture Design SOP Owner: 1231111 Summary: Produces a complete software architecture design document following a 12-phase SOP. Supports web backend, mobile, ML/AI, data pipeline, embedded/IoT. Generat... Tags: architecture:1.1.0, latest:1.1.0, mermaid:1.1.0, plantuml:1.1.0, sop:1.1.0, system-design:1.1.0 Version history: v1.1.0 | 2026-05-28T03:01:16.413Z | user Initial public release: 12-phase SO","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.1K downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s17e7zph9qn5y9mzfzrhqew20n87keef:software-architecture-design","sourceUrl":"https://clawhub.ai/1231111/software-architecture-design","homepage":"https://clawhub.ai/1231111/skills/software-architecture-design","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/1231111/software-architecture-design","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/1231111/skills/software-architecture-design","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":61,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Produces a complete software architecture design document following a 12-phase SOP. Supports web backend, mobile, ML/AI, data pipeline, embedded/IoT. Generat..."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T07:07:53.517Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T07:07:53.517Z","emptyReason":null},"stars":null,"forks":null,"downloads":1127,"packageName":null,"latestVersion":"1.1.0","tractionLabel":"1.1K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T07:07:53.457Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T07:07:53.517Z","lastCrawledAt":"2026-10-11T07:07:53.457Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T07:07:53.457Z","lastVerifiedAt":null,"highlights":[{"version":"1.1.0","createdAt":"2026-05-28T03:01:16.413Z","changelog":"Initial public release: 12-phase SOP supporting web backend, ML/AI, data pipeline, embedded, mobile. 8 diagram templates with Mermaid and PlantUML.","fileCount":11,"zipByteSize":29169}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17e7zph9qn5y9mzfzrhqew20n87keef:software-architecture-design","setupComplexity":"low","setupSteps":["Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-1231111-software-architecture-design/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-1231111-software-architecture-design/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-1231111-software-architecture-design/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-1231111-software-architecture-design/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-1231111-software-architecture-design/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-1231111-software-architecture-design/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-11T10:51:16.046Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-1231111-software-architecture-design/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-1231111-software-architecture-design/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-1231111-software-architecture-design/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-1231111-software-architecture-design/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-11T07:07:53.517Z","emptyReason":null},"readme":"Skill: Software Architecture Design SOP\n\nOwner: 1231111\n\nSummary: Produces a complete software architecture design document following a 12-phase SOP. Supports web backend, mobile, ML/AI, data pipeline, embedded/IoT. Generat...\n\nTags: architecture:1.1.0, latest:1.1.0, mermaid:1.1.0, plantuml:1.1.0, sop:1.1.0, system-design:1.1.0\n\nVersion history:\n\nv1.1.0 | 2026-05-28T03:01:16.413Z | user\n\nInitial public release: 12-phase SOP supporting web backend, ML/AI, data pipeline, embedded, mobile. 8 diagram templates with Mermaid and PlantUML.\n\nArchive index:\n\nArchive v1.1.0: 11 files, 29169 bytes\n\nFiles: reference.md (9592b), skill-card.md (2742b), SKILL.md (8215b), specializations/data-pipeline.md (3745b), specializations/embedded.md (3956b), specializations/ml-system.md (3898b), specializations/mobile.md (4209b), specializations/web-backend.md (3415b), STANDALONE.md (13752b), template.md (5946b), _meta.json (147b)\n\nFile v1.1.0:SKILL.md\n\n---\r\nname: software-architecture-design\r\nversion: 1.1.0\r\nauthor: sunbinbin\r\nlicense: MIT\r\ntags: architecture, system-design, technical-design, sop, mermaid, plantuml, web, mobile, ml, embedded, data-pipeline\r\ndescription: \"Produces a complete software architecture design document following a 12-phase SOP. Supports web backend, mobile, ML/AI, data pipeline, embedded/IoT. Generates Mermaid and PlantUML diagrams. Use when asked to do architecture design, system design, technical design, or says: 做架构设计 系统设计 技术方案 架构文档.\"\r\nmetadata: {\"openclaw\": {\"emoji\": \"🏗️\", \"os\": [\"darwin\", \"linux\", \"win32\"]}}\r\n---\r\n\r\n# Software Architecture Design SOP\r\n\r\n## Step 0 — Identify Architecture Type First\r\n\r\nBefore starting the 12 phases, identify the architecture type and load the matching specialization:\r\n\r\n| Type | Trigger keywords | Specialization file |\r\n|------|-----------------|---------------------|\r\n| Web / API backend | API, 后端, 服务端, REST, 微服务, SaaS | `{baseDir}/specializations/web-backend.md` |\r\n| ML / AI system | 模型, 推理, 训练, 算法平台, AI, LLM | `{baseDir}/specializations/ml-system.md` |\r\n| Data pipeline | ETL, 数据仓库, 数据湖, Kafka, Spark | `{baseDir}/specializations/data-pipeline.md` |\r\n| Embedded / IoT | 嵌入式, 固件, MCU, RTOS, 硬件, CAN | `{baseDir}/specializations/embedded.md` |\r\n| Mobile app | iOS, Android, Flutter, React Native | `{baseDir}/specializations/mobile.md` |\r\n| General / Mixed | (none of the above match clearly) | Use base SOP only |\r\n\r\nRead the matched specialization file for domain-specific guidance on Phases 3, 6, 7, 9.\r\n\r\n---\r\n\r\n## Core Principles (apply throughout)\r\n\r\n- **Constraint-driven** — Every decision traces back to a hard constraint (compliance, budget, team, deployment env).\r\n- **Decision explicit** — For every non-trivial choice, show Option A vs Option B and the reason for selection.\r\n- **MVP-first** — Define a clear MVP boundary. Defer everything not critical to v1.\r\n- **Diagram every concept** — Each major phase produces at least one diagram (see diagram guide in `{baseDir}/reference.md`).\r\n- **Executable** — The architecture must be buildable by the stated team with the stated tech stack.\r\n\r\n---\r\n\r\n## Phase 1 — Requirement Intake\r\n\r\n**Input**: Requirements doc, RFP, PRD, user stories, or verbal description.\r\n\r\n1. Classify all requirements:\r\n   - **Functional** — what the system does (features, user journeys)\r\n   - **Non-functional** — performance, availability SLA, latency, throughput, data volume\r\n   - **Compliance / regulatory** — industry standards, data residency, audit requirements\r\n   - **Deployment constraints** — air-gap, on-prem, cloud, edge, hardware limits, OS\r\n2. List the top 5 user roles and their primary use cases.\r\n3. Capture all explicit exclusions (\"out of scope\").\r\n4. List open questions / ambiguities — ask the user to resolve before proceeding.\r\n\r\n---\r\n\r\n## Phase 2 — System Context & Boundary\r\n\r\n1. Draw **System Context Diagram** (C4 Level 1): system as a black box + external actors + external systems.\r\n2. Define MVP delivery boundary — two tables:\r\n   - **MVP Includes**: feature / category / success criteria\r\n   - **MVP Excludes**: feature / deferred to version / reason\r\n3. State **performance targets** as a table: metric / target value / measurement method.\r\n\r\n---\r\n\r\n## Phase 3 — Layered Architecture\r\n\r\n1. Select the architecture pattern and justify it against Phase 1 constraints:\r\n   - Options: Layered (N-tier), Event-driven, Microservices, Plugin-based, Pipe-and-filter, Serverless, Monolith-first\r\n2. Define 3–5 layers: name / responsibility / key technologies / protocol to adjacent layer.\r\n3. Produce **Layer Architecture Diagram**.\r\n4. Refer to the loaded specialization for domain-specific layer guidance.\r\n\r\n---\r\n\r\n## Phase 4 — Module Decomposition\r\n\r\n1. Decompose each layer into cohesive, single-responsibility modules.\r\n2. Draw **Module Dependency Diagram** (DAG — must have no cycles).\r\n3. For each module: name / layer / one-sentence responsibility / key technology.\r\n\r\n---\r\n\r\n## Phase 5 — Core Business Flows\r\n\r\n1. Identify the 3–7 most critical end-to-end flows.\r\n2. For each flow: draw a **Sequence Diagram** or **Flowchart**.\r\n3. For stateful entities: define **State Machine** (states + transitions + error states).\r\n4. Document exception handling: what fails → what recovers → who is notified.\r\n\r\n---\r\n\r\n## Phase 6 — Data Architecture\r\n\r\n1. Draw **ER Diagram** covering all core entities.\r\n2. Storage selection table: data type → storage component → justification.\r\n   - Rule: choose the simplest storage that meets the requirement. Escalate only when constrained.\r\n3. Define key entity schemas: name / critical fields / types / indexes.\r\n4. Data lifecycle: retention policy / archival / backup strategy.\r\n\r\n---\r\n\r\n## Phase 7 — Technology Selection\r\n\r\n1. For each component category, compare **exactly two options** (A vs B selected).\r\n2. Produce **Tech Stack Table**: category / selection / version / rationale.\r\n3. Validate every selection against Phase 1 constraints (offline? open-source license? team skill?).\r\n4. Record deliberate technical debt: \"Chose X for MVP; plan to migrate to Y in vN because...\".\r\n\r\n---\r\n\r\n## Phase 8 — Interface Design\r\n\r\n1. **External API**: all endpoints in a table — method / path / purpose / sync or async / auth required.\r\n2. **Extension contract (SPI/plugin)**: if the system is extensible, define the standard interface every extension must implement.\r\n3. **Async protocols**: describe WebSocket, SSE, or message queue contracts.\r\n4. **Error schema**: standard error response format + error code list.\r\n5. **Versioning strategy**: URL path versioning (`/v1/`) or header-based.\r\n\r\n---\r\n\r\n## Phase 9 — Deployment Architecture\r\n\r\n1. Draw **Deployment Topology Diagram**.\r\n2. Server / hardware specs table: scenario / specs / notes.\r\n3. All runtime components: name / role / port or address / resource requirements / restart policy.\r\n4. Data flow between components: what data, which protocol, sync or async.\r\n5. CI/CD pipeline: trigger → build → test → package → deploy steps.\r\n6. Refer to the loaded specialization for deployment model specifics.\r\n\r\n---\r\n\r\n## Phase 10 — Non-Functional Design\r\n\r\nAddress all four areas:\r\n\r\n| Area | Required content |\r\n|------|-----------------|\r\n| **High Availability** | Per failure scenario: what breaks, recovery action, RTO target |\r\n| **Performance** | Each NFR target + specific implementation strategy to achieve it |\r\n| **Security** | Auth/authz model, data isolation, secrets management, audit logging |\r\n| **Observability** | MVP-phase monitoring (health endpoints, key logs) → full metrics plan |\r\n\r\n---\r\n\r\n## Phase 11 — MVP Scope Lock\r\n\r\n1. Finalize **MVP Includes / Excludes** tables with target versions.\r\n2. State **success criteria** — measurable conditions that define MVP as \"done\".\r\n3. List all technical debt decisions with rationale.\r\n\r\n---\r\n\r\n## Phase 12 — Risk Register\r\n\r\nRisk table: description / probability (H/M/L) / impact (H/M/L) / mitigation strategy.\r\n\r\nMust include at least one risk from each category:\r\n- Dependency (3rd-party libs, hardware, external APIs)\r\n- Integration (external systems, compliance verification)\r\n- Delivery (scope creep, unknowns requiring POC, timeline)\r\n\r\n---\r\n\r\n## Diagram Generation Guide\r\n\r\nFor every diagram, produce Mermaid code (preferred) or PlantUML code. See `{baseDir}/reference.md` for templates and when to use which tool.\r\n\r\n| Phase | Diagram | Tool |\r\n|-------|---------|------|\r\n| 2 | System Context | Mermaid C4 or PlantUML C4 |\r\n| 3 | Layer Architecture | PlantUML component or Mermaid graph |\r\n| 4 | Module Dependencies | Mermaid graph TD |\r\n| 5 | Sequence / Flow | Mermaid sequenceDiagram / flowchart |\r\n| 5 | State Machine | Mermaid stateDiagram-v2 |\r\n| 6 | ER Diagram | Mermaid erDiagram |\r\n| 9 | Deployment Topology | PlantUML deployment |\r\n| 9 | CI/CD Pipeline | Mermaid flowchart LR |\r\n\r\n---\r\n\r\n## Output\r\n\r\nFollow the document chapter structure in `{baseDir}/template.md`.\r\nAfter all 12 phases, self-check against the phase-by-phase checklist in `{baseDir}/reference.md`.\n\nFile v1.1.0:_meta.json\n\n{\n  \"ownerId\": \"kn7fp5s80ck78fqh36fht9sdcd87jhp9\",\n  \"slug\": \"software-architecture-design\",\n  \"version\": \"1.1.0\",\n  \"publishedAt\": 1779937276413\n}\n\nFile v1.1.0:reference.md\n\n# Architecture Design — Reference\r\n\r\n## Phase-by-Phase Checklist\r\n\r\n### Phase 1: Requirement Intake\r\n- [ ] All source documents read in full\r\n- [ ] Functional requirements listed and numbered\r\n- [ ] Non-functional: performance, availability, latency, throughput, data volume\r\n- [ ] Compliance standards identified (ISO, GDPR, HIPAA, GB, IEC, etc.)\r\n- [ ] Deployment constraints captured (air-gap, GPU, OS, cloud/on-prem, hardware)\r\n- [ ] Top 5 user roles and use cases written\r\n- [ ] Open questions listed for user to resolve\r\n\r\n### Phase 2: System Context & Boundary\r\n- [ ] System Context Diagram exists with all external actors and systems labeled\r\n- [ ] MVP Includes table with success criteria per feature\r\n- [ ] MVP Excludes table with target version per exclusion\r\n- [ ] Performance targets table with measurement method\r\n\r\n### Phase 3: Layered Architecture\r\n- [ ] Architecture pattern named and justified against constraints\r\n- [ ] Every layer: name / stack / responsibility / inter-layer protocol\r\n- [ ] Layer architecture diagram exists\r\n\r\n### Phase 4: Module Decomposition\r\n- [ ] Every module: one-sentence responsibility\r\n- [ ] No circular dependencies (verified)\r\n- [ ] Module dependency diagram exists (DAG)\r\n\r\n### Phase 5: Core Business Flows\r\n- [ ] At least 3 critical flows documented with diagrams\r\n- [ ] State machines for all stateful entities\r\n- [ ] Exception paths documented per flow\r\n\r\n### Phase 6: Data Architecture\r\n- [ ] ER diagram covering all core entities\r\n- [ ] Storage selection justified per data type\r\n- [ ] Key schemas with field names and types\r\n- [ ] Backup / retention policy stated\r\n\r\n### Phase 7: Technology Selection\r\n- [ ] Option A vs Option B table for each component\r\n- [ ] Each selection validated against Phase 1 constraints\r\n- [ ] No orphaned technologies (every tech appears in the architecture)\r\n- [ ] Deliberate tech debt documented with rationale\r\n\r\n### Phase 8: Interface Design\r\n- [ ] All endpoints in a table (method, path, purpose, sync/async, auth)\r\n- [ ] SPI/plugin contract defined if extensibility required\r\n- [ ] Async protocol (WebSocket / SSE / queue) described\r\n- [ ] Error response schema defined\r\n- [ ] Versioning strategy stated\r\n\r\n### Phase 9: Deployment Architecture\r\n- [ ] Deployment topology diagram exists\r\n- [ ] Server/hardware specs for min / recommended / production\r\n- [ ] All runtime components with ports and resource requirements\r\n- [ ] Volume / filesystem / data flow described\r\n- [ ] CI/CD pipeline steps listed\r\n\r\n### Phase 10: Non-Functional Design\r\n- [ ] HA: failure scenarios and recovery strategies\r\n- [ ] Performance: each metric + implementation strategy\r\n- [ ] Security: auth, secrets, data isolation, audit\r\n- [ ] Observability: MVP health endpoints + future metrics plan\r\n\r\n### Phase 11: MVP Scope Lock\r\n- [ ] MVP Includes / Excludes finalized\r\n- [ ] Success criteria measurable\r\n- [ ] Tech debt register complete\r\n\r\n### Phase 12: Risk Register\r\n- [ ] ≥ 5 risks documented\r\n- [ ] Each risk: probability + impact + mitigation\r\n- [ ] At least one dependency, one integration, one delivery risk\r\n\r\n---\r\n\r\n## Common Mistakes to Avoid\r\n\r\n### Over-engineering for MVP\r\nChoose the simplest technology that satisfies the constraint. Only escalate when you hit a documented limit.\r\n\r\nExample pattern:\r\n- Storage: local file → SQLite → PostgreSQL → distributed DB (escalate only when constrained)\r\n- Queue: in-process queue → Redis → Kafka (escalate only when constrained)\r\n- Deploy: single process → containers → orchestration (escalate only when constrained)\r\n\r\n### Missing the \"why\" in decisions\r\nBad: \"We use X for the job queue.\"\r\nGood: \"We use X because the requirement states tasks run for hours and must survive process restarts — an in-memory queue would lose tasks on crash.\"\r\n\r\n### Underdefined extension contracts\r\nIf the system has plugins, webhooks, or adapters: define the interface precisely before implementation starts. Vague descriptions cause integration failures.\r\n\r\n### No MVP boundary\r\nDefine MVP as: the minimum set of capabilities that delivers the stated value proposition. Every feature not in MVP gets a target version and a reason.\r\n\r\n### Diagrams without labels\r\nEvery diagram must have: title, labeled nodes/actors, labeled edges (protocol + data), one-line caption.\r\n\r\n### Architecture mismatch with constraints\r\nExample: designing a stateless microservice when the deployment environment has no container orchestration. Every architecture decision must be validated against Phase 1 constraints.\r\n\r\n---\r\n\r\n## Decision Framework\r\n\r\nFor every significant technology or design decision:\r\n\r\n| Dimension | Option A | Option B (selected) |\r\n|-----------|----------|---------------------|\r\n| Complexity to implement | | |\r\n| Operational overhead | | |\r\n| Scalability ceiling | | |\r\n| Team familiarity | | |\r\n| License / cost | | |\r\n| Constraint fit (list which constraints it satisfies/fails) | | |\r\n| **Verdict** | | ✓ Selected because: |\r\n\r\n---\r\n\r\n## Diagram Generation Guide\r\n\r\n### Tool selection\r\n\r\n| Situation | Use |\r\n|-----------|-----|\r\n| Sequence, flowchart, state, ER, simple graph | **Mermaid** — renders in GitHub, Notion, Typora, Cursor |\r\n| C4 context/container/component, deployment topology, layered box-in-box | **PlantUML** — more expressive for structural diagrams |\r\n| Cannot use either tool | Describe in structured text with ASCII art outline |\r\n\r\n---\r\n\r\n### 1. System Context Diagram (Phase 2) — Mermaid C4\r\n\r\n```mermaid\r\nC4Context\r\n  title System Context — [System Name]\r\n  Person(user, \"Primary User\", \"Description of user role\")\r\n  Person(admin, \"Admin\", \"Description of admin role\")\r\n  System(system, \"[System Name]\", \"What this system does\")\r\n  System_Ext(extA, \"External System A\", \"What it provides\")\r\n  System_Ext(extB, \"External System B\", \"What it provides\")\r\n  Rel(user, system, \"Uses\", \"HTTPS\")\r\n  Rel(system, extA, \"Reads from\", \"REST API\")\r\n  Rel(system, extB, \"Sends to\", \"Webhook\")\r\n```\r\n\r\n---\r\n\r\n### 2. Layer Architecture Diagram (Phase 3) — PlantUML\r\n\r\n```plantuml\r\n@startuml layer-architecture\r\nskinparam rectangle {\r\n  BackgroundColor<<layer>> LightBlue\r\n}\r\ntitle Layer Architecture — [System Name]\r\n\r\nrectangle \"Presentation Layer\" <<layer>> {\r\n  component [UI / Client]\r\n}\r\nrectangle \"Application Layer\" <<layer>> {\r\n  component [Business Logic]\r\n  component [Orchestration]\r\n}\r\nrectangle \"Data Layer\" <<layer>> {\r\n  component [Repository]\r\n  component [Cache]\r\n}\r\nrectangle \"Infrastructure Layer\" <<layer>> {\r\n  component [DB]\r\n  component [Queue]\r\n  component [Storage]\r\n}\r\n\r\n[UI / Client] --> [Business Logic] : HTTP/REST\r\n[Business Logic] --> [Repository] : ORM\r\n[Orchestration] --> [Queue] : publish\r\n@enduml\r\n```\r\n\r\n---\r\n\r\n### 3. Module Dependency Diagram (Phase 4) — Mermaid\r\n\r\n```mermaid\r\ngraph TD\r\n  A[ModuleA] --> B[ModuleB]\r\n  A --> C[ModuleC]\r\n  B --> D[ModuleD]\r\n  C --> D\r\n  D --> E[SharedInfra]\r\n  style A fill:#dae8fc\r\n  style E fill:#d5e8d4\r\n```\r\n\r\n---\r\n\r\n### 4. Sequence Diagram (Phase 5) — Mermaid\r\n\r\n```mermaid\r\nsequenceDiagram\r\n  actor User\r\n  participant Frontend\r\n  participant Backend\r\n  participant DB\r\n\r\n  User->>Frontend: Action\r\n  Frontend->>Backend: POST /api/v1/resource\r\n  Backend->>DB: INSERT\r\n  DB-->>Backend: OK\r\n  Backend-->>Frontend: 201 Created {id}\r\n  Frontend-->>User: Success feedback\r\n\r\n  alt Error case\r\n    Backend-->>Frontend: 4xx/5xx {error}\r\n    Frontend-->>User: Error message\r\n  end\r\n```\r\n\r\n---\r\n\r\n### 5. State Machine (Phase 5) — Mermaid\r\n\r\n```mermaid\r\nstateDiagram-v2\r\n  [*] --> CREATED\r\n  CREATED --> PROCESSING : trigger / condition\r\n  PROCESSING --> COMPLETED : success\r\n  PROCESSING --> FAILED : error\r\n  FAILED --> PROCESSING : retry (max 3)\r\n  COMPLETED --> [*]\r\n  FAILED --> [*] : max retries exceeded\r\n\r\n  note right of PROCESSING : Include timeout handling\r\n```\r\n\r\n---\r\n\r\n### 6. ER Diagram (Phase 6) — Mermaid\r\n\r\n```mermaid\r\nerDiagram\r\n  ENTITY_A {\r\n    uuid id PK\r\n    string name\r\n    timestamp created_at\r\n  }\r\n  ENTITY_B {\r\n    uuid id PK\r\n    uuid entity_a_id FK\r\n    json metadata\r\n  }\r\n  ENTITY_C {\r\n    uuid id PK\r\n    string type\r\n  }\r\n\r\n  ENTITY_A ||--o{ ENTITY_B : \"has many\"\r\n  ENTITY_B }o--|| ENTITY_C : \"belongs to\"\r\n```\r\n\r\n---\r\n\r\n### 7. Deployment Topology (Phase 9) — PlantUML\r\n\r\n```plantuml\r\n@startuml deployment\r\nskinparam node {\r\n  BackgroundColor LightYellow\r\n}\r\ntitle Deployment Topology — [System Name]\r\n\r\nnode \"Client Machine\" {\r\n  component [Browser / App]\r\n}\r\n\r\nnode \"Application Server\" {\r\n  component [Web Server / API]\r\n  component [Worker]\r\n}\r\n\r\nnode \"Data Server\" {\r\n  database [Primary DB]\r\n  database [Cache]\r\n  storage [Object Storage]\r\n}\r\n\r\n[Browser / App] --> [Web Server / API] : HTTPS :443\r\n[Web Server / API] --> [Worker] : Queue\r\n[Web Server / API] --> [Primary DB] : TCP :5432\r\n[Web Server / API] --> [Cache] : TCP :6379\r\n[Worker] --> [Object Storage] : S3 API\r\n@enduml\r\n```\r\n\r\n---\r\n\r\n### 8. CI/CD Pipeline (Phase 9) — Mermaid\r\n\r\n```mermaid\r\nflowchart LR\r\n  A([git push / PR]) --> B[Lint & Static Analysis]\r\n  B --> C[Unit Tests]\r\n  C --> D[Build Artifact]\r\n  D --> E[Integration Tests]\r\n  E --> F{Branch?}\r\n  F -->|main| G[Deploy to Staging]\r\n  F -->|tag| H[Deploy to Production]\r\n  G --> I[Smoke Tests]\r\n  H --> J[Release Notes]\r\n```\r\n\r\n---\r\n\r\n## Diagram Rendering Environments\r\n\r\n| Environment | Mermaid | PlantUML |\r\n|-------------|---------|----------|\r\n| GitHub Markdown | ✅ Native | ❌ Need plugin |\r\n| Typora | ✅ | ✅ (with config) |\r\n| Cursor IDE | ✅ | ✅ |\r\n| Notion | ✅ (via block) | ❌ |\r\n| draw.io | ❌ | ✅ (import) |\r\n| VS Code | ✅ (extension) | ✅ (extension) |\n\nFile v1.1.0:skill-card.md\n\n## Description:\n\nProduces complete software architecture design documents through a 12-phase SOP for web backend, mobile, ML/AI, data pipeline, and embedded/IoT systems, with Mermaid and PlantUML diagram guidance.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[1231111](https://clawhub.ai/user/1231111)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and engineers use this skill to turn requirements, PRDs, RFPs, or verbal system descriptions into structured architecture design documents with MVP scope, architecture decisions, interfaces, deployment, non-functional design, and risk registers.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Generated ML/AI architecture guidance may include detailed health endpoints that expose resource status if copied directly into production designs.\n\nMitigation: Keep public liveness checks minimal and move detailed health and resource reporting to authenticated internal metrics endpoints before production use.\n\nRisk: The default output template is Chinese, which may not match every team's documentation language.\n\nMitigation: Ask the agent for the required output language at the start of the architecture-design request.\n\nRisk: Architecture proposals can be incomplete or misaligned when requirements are ambiguous.\n\nMitigation: Resolve the Phase 1 open questions and review generated decisions, diagrams, and risk registers with domain owners before adoption.\n\n## Reference(s):\n\n- [Architecture Design Reference](artifact/reference.md)\n- [Architecture Design Document Template](artifact/template.md)\n- [Standalone Software Architecture Design SOP](artifact/STANDALONE.md)\n- [Web / API Backend Specialization](artifact/specializations/web-backend.md)\n- [ML / AI System Specialization](artifact/specializations/ml-system.md)\n- [Data Pipeline / Data Platform Specialization](artifact/specializations/data-pipeline.md)\n- [Embedded / IoT System Specialization](artifact/specializations/embedded.md)\n- [Mobile App Specialization](artifact/specializations/mobile.md)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Code, Guidance]\n\n**Output Format:** [Markdown architecture document with Mermaid and PlantUML code blocks]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Default output template is Chinese unless the user asks for another language.]\n\n## Skill Version(s):\n\n1.1.0 (source: frontmatter and server release metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nFile v1.1.0:specializations/data-pipeline.md\n\n# Specialization: Data Pipeline / Data Platform\r\n\r\nApply this guidance for ETL, ELT, data warehouse, data lake, streaming, and analytics platform designs.\r\n\r\n## Phase 3 — Data Pipeline Architecture Patterns\r\n\r\n| Pattern | When to choose |\r\n|---------|---------------|\r\n| Batch ETL | Latency tolerance hours/days; large volume; simple transforms |\r\n| Streaming (Lambda) | Real-time + batch coexist; complex state management |\r\n| Streaming-only (Kappa) | All processing as streams; late data handled by reprocessing |\r\n| ELT (load first, transform in warehouse) | Cloud DW available; raw data preservation needed |\r\n| Medallion (Bronze/Silver/Gold) | Data lake; incremental quality improvement; multiple consumer types |\r\n\r\n## Phase 5 — Critical Flows for Data Pipelines\r\n\r\n1. **Ingestion flow**: source → extract → validate → land (raw)\r\n2. **Transform flow**: raw → clean → enrich → aggregate\r\n3. **Serving flow**: aggregated data → query engine → consumer (BI, API, ML)\r\n4. **Backfill / reprocessing flow**: historical data re-ingestion on schema/logic change\r\n5. **Data quality check flow**: record → validation rules → quarantine or pass\r\n\r\n## Phase 6 — Storage Layers\r\n\r\n| Layer | Purpose | Technology options |\r\n|-------|---------|-------------------|\r\n| Landing (raw) | Exact copy of source, immutable | Object storage (S3/MinIO), file system |\r\n| Staging | Cleaned, typed, deduplicated | Parquet on object storage |\r\n| Curated | Business-ready aggregates | Data warehouse (PostgreSQL, ClickHouse, BigQuery) |\r\n| Serving | Low-latency query | Columnar DB, materialized views, Redis cache |\r\n| Metadata | Lineage, schema, quality stats | Relational DB (PostgreSQL) |\r\n\r\n## Phase 7 — Data Pipeline Decision Points\r\n\r\n| Decision | Key question | Options |\r\n|----------|-------------|---------|\r\n| Batch vs stream | What is the acceptable latency? | minutes → micro-batch; seconds → streaming |\r\n| Orchestration | How many pipelines? Complex dependencies? | Cron → Airflow → Prefect/Dagster |\r\n| Transform engine | Data volume? Team language? | SQL (dbt) vs Python (Spark/Pandas) vs Beam |\r\n| Messaging | Throughput and durability? | Redis Streams → RabbitMQ → Kafka |\r\n| Schema management | Schema evolution needed? | None → JSON Schema → Avro/Protobuf |\r\n\r\n## Phase 8 — Data Pipeline Interface Design\r\n\r\nDefine these contracts explicitly:\r\n\r\n- **Source connectors**: protocol, auth, extraction mode (full / incremental / CDC), rate limits\r\n- **Schema registry**: where schemas are defined, how consumers discover them\r\n- **Data quality contract**: which fields are required, valid ranges, uniqueness constraints\r\n- **SLA contract**: ingestion frequency, max latency, freshness guarantee\r\n\r\n## Phase 9 — Deployment Patterns\r\n\r\n| Pattern | Scale | Notes |\r\n|---------|-------|-------|\r\n| Single server + cron | Small, < 10 pipelines | Simple, low ops overhead |\r\n| Docker Compose + Airflow | Medium, < 100 pipelines | Managed scheduling |\r\n| Kubernetes + Helm | Large, 100+ pipelines, multi-tenant | Complex ops, full isolation |\r\n| Cloud-managed (Glue, Dataflow) | Cloud-first | Reduces ops, higher cost |\r\n\r\n## Phase 10 — Data Pipeline NFR\r\n\r\n- **Idempotency**: every pipeline run must be safe to re-run without duplicating data\r\n- **Exactly-once semantics**: define per pipeline whether at-least-once or exactly-once is required\r\n- **Data retention**: define per layer — raw data kept longer than curated\r\n- **Lineage tracking**: every output table must know its source tables and transform version\r\n- **Alerting on data quality**: failed quality checks must trigger alerts, not silently pass bad data\r\n- **Backpressure**: streaming pipelines must handle source bursts without data loss\n\nFile v1.1.0:specializations/embedded.md\n\n# Specialization: Embedded / IoT System\r\n\r\nApply this guidance for firmware, MCU systems, RTOS-based designs, hardware abstraction layers, and IoT edge devices.\r\n\r\n## Phase 3 — Embedded Architecture Patterns\r\n\r\n| Pattern | When to choose |\r\n|---------|---------------|\r\n| Bare-metal (super loop) | Simple device, deterministic timing, no OS needed |\r\n| RTOS task-based | Multiple concurrent behaviors, timing constraints |\r\n| Hardware Abstraction Layer (HAL) | Portability across hardware variants required |\r\n| Edge + Cloud hybrid | Local processing + cloud sync; offline-capable |\r\n| Firmware OTA | Field-deployed devices requiring remote update |\r\n\r\nMandatory layer for any embedded system with hardware variants:\r\n\r\n```\r\nApplication Logic\r\n      ↓\r\nHardware Abstraction Layer (HAL)\r\n      ↓\r\nBoard Support Package (BSP) / Drivers\r\n      ↓\r\nPhysical Hardware\r\n```\r\n\r\n## Phase 5 — Critical Flows for Embedded Systems\r\n\r\n1. **Boot / initialization flow**: power-on → hardware init → self-test → main loop\r\n2. **Interrupt service flow**: hardware event → ISR → flag/queue → task handler\r\n3. **Communication protocol flow**: frame receive → parse → validate → dispatch → respond\r\n4. **OTA update flow**: check version → download → verify checksum → apply → reboot\r\n5. **Fault / error handling flow**: detect → log → safe state → notify\r\n\r\n## Phase 6 — Storage in Embedded\r\n\r\n| Data type | Storage option | Notes |\r\n|-----------|---------------|-------|\r\n| Firmware image | Internal flash | Dual-bank for safe OTA |\r\n| Configuration | EEPROM or flash with wear leveling | |\r\n| Runtime logs | SRAM ring buffer → external flash | Circular overwrite |\r\n| Calibration data | Non-volatile (FRAM / EEPROM) | |\r\n| Streaming sensor data | FIFO buffer → UART/SPI to host | |\r\n\r\n## Phase 7 — Embedded-Specific Decision Points\r\n\r\n| Decision | Options | Key constraint |\r\n|----------|---------|---------------|\r\n| RTOS vs bare-metal | FreeRTOS, Zephyr vs super-loop | Determinism and task count |\r\n| Communication bus | UART, SPI, I2C, CAN, USB, Ethernet | Speed, distance, node count |\r\n| Memory allocation | Static only vs dynamic | Safety-critical → static only |\r\n| Bootloader | Custom vs MCUboot | OTA needed → use standard bootloader |\r\n| HAL approach | Custom HAL vs vendor SDK HAL | Portability requirement |\r\n\r\n## Phase 8 — Interface Design for Embedded\r\n\r\nDefine these communication contracts:\r\n\r\n- **Hardware interface**: pin mapping, voltage levels, timing diagrams, protocol (CAN frame format, UART baud rate, SPI mode)\r\n- **Host / cloud interface**: protocol (MQTT, CoAP, HTTP), message schema, QoS, reconnect behavior\r\n- **Debug interface**: UART log format, JTAG/SWD access, remote shell commands\r\n- **OTA interface**: package format, signature verification, rollback mechanism\r\n\r\n## Phase 9 — Deployment for Embedded\r\n\r\n| Artifact | Notes |\r\n|----------|-------|\r\n| Firmware binary | Checksum + version metadata embedded |\r\n| Programming tool | Specify flasher tool + config (J-Link, OpenOCD, etc.) |\r\n| Factory programming | Jig procedure, test coverage, pass/fail criteria |\r\n| Field update | OTA mechanism, fallback image, minimum power requirement |\r\n| CI/CD | Cross-compile toolchain, unit tests on host (mocking HAL), HIL tests |\r\n\r\n## Phase 10 — Embedded NFR\r\n\r\n- **Timing constraints**: define hard real-time (missed deadline = failure) vs soft real-time; specify worst-case execution time for critical ISRs\r\n- **Memory budget**: document RAM and flash usage per module; set hard limits\r\n- **Power budget**: define sleep modes, wake sources, maximum current draw per state\r\n- **Watchdog**: hardware watchdog must be enabled and kicked by application, never in ISR\r\n- **Fail-safe state**: define what the device does on any unhandled error (safe outputs, halt, reboot)\r\n- **EMC / environmental**: note operating temperature range, vibration, humidity, CE/FCC compliance requirements\n\nFile v1.1.0:specializations/ml-system.md\n\n# Specialization: ML / AI System\r\n\r\nApply this guidance on top of the base SOP for AI/ML platforms, model serving, algorithm pipelines, and LLM applications.\r\n\r\n## Phase 3 — ML System Layer Pattern\r\n\r\nTypical 4-layer pattern for ML systems:\r\n\r\n| Layer | Responsibility |\r\n|-------|---------------|\r\n| **Serving / Application** | API gateway, user interface, request routing |\r\n| **Orchestration** | Experiment tracking, pipeline scheduling, task queue |\r\n| **Execution / Compute** | Model training workers, inference servers, GPU scheduling |\r\n| **Storage / Registry** | Model registry, feature store, dataset store, artifact store |\r\n\r\n## Phase 5 — Critical Flows for ML Systems\r\n\r\nAlways document these flows (in addition to general business flows):\r\n\r\n1. **Model training flow**: data ingestion → preprocessing → training → evaluation → registration\r\n2. **Inference / serving flow**: request → preprocessing → model forward pass → postprocessing → response\r\n3. **Model promotion flow**: experiment → staging validation → production promotion → rollback\r\n4. **Data pipeline flow**: source → ingestion → validation → feature engineering → storage\r\n\r\n## Phase 6 — Storage Selection for ML\r\n\r\n| Data type | Storage choice | Notes |\r\n|-----------|---------------|-------|\r\n| Model weights / artifacts | Object storage (MinIO, S3) | Versioned, immutable |\r\n| Experiment metadata | Relational DB or MLflow tracking | Query by params, metrics |\r\n| Features (batch) | Data warehouse / Parquet on object storage | |\r\n| Features (online) | Redis / DynamoDB | Low-latency lookup |\r\n| Training datasets | Object storage + metadata DB | Large files, never copy |\r\n| Inference logs | Time-series DB or object storage | Monitoring, drift detection |\r\n\r\n## Phase 7 — ML-Specific Decision Points\r\n\r\n| Decision | Consideration |\r\n|----------|--------------|\r\n| Online vs batch inference | Latency SLA < 100ms → online; throughput-first → batch |\r\n| GPU scheduling | Dynamic memory allocation vs fixed slot reservation |\r\n| Model isolation | Shared process (fast) vs Docker container per model (safe, isolated) |\r\n| Framework | PyTorch for research flexibility; ONNX for cross-platform serving |\r\n| Feature store | Only add if serving features to multiple models; otherwise compute inline |\r\n| Experiment tracking | MLflow (self-hosted) vs Weights & Biases (cloud) vs custom |\r\n\r\n## Phase 8 — ML Inference API Standards\r\n\r\nStandard inference endpoint pattern:\r\n\r\n```\r\nPOST /api/v1/predict\r\n{\r\n  \"model_id\": \"string\",\r\n  \"inputs\": { ... }       // model-specific input schema\r\n}\r\n→ 200 {\r\n  \"prediction\": { ... },  // model-specific output schema\r\n  \"model_version\": \"1.0\",\r\n  \"latency_ms\": 42\r\n}\r\n```\r\n\r\nHealth endpoint must report resource status:\r\n```\r\nGET /health\r\n→ { \"status\": \"ok\", \"gpu_memory_free_mb\": 8192, \"model_loaded\": true }\r\n```\r\n\r\n## Phase 9 — Deployment Patterns for ML\r\n\r\n| Pattern | When to use |\r\n|---------|------------|\r\n| Single host, Docker Compose | Private deployment, single GPU workstation, offline |\r\n| Model server (Triton, TorchServe) | Multiple models, batching, dynamic batching |\r\n| Kubernetes + GPU node pool | Multi-tenant, auto-scaling, multiple GPU types |\r\n| Serverless inference | CPU-only, short bursts, cold start acceptable |\r\n\r\n## Phase 10 — ML-Specific NFR\r\n\r\n- **Model drift monitoring**: log inputs/outputs; schedule periodic drift detection\r\n- **GPU memory management**: always report free memory in `/health`; schedule tasks against available memory not fixed slots\r\n- **Reproducibility**: pin all library versions; store random seeds with experiment metadata\r\n- **Data lineage**: record which dataset version produced which model version\r\n- **Fairness / bias**: define evaluation metrics beyond accuracy for safety-critical systems\r\n- **Inference latency SLA**: define P50 / P95 / P99 latency targets separately\n\nFile v1.1.0:specializations/mobile.md\n\n# Specialization: Mobile App\r\n\r\nApply this guidance for iOS, Android, Flutter, React Native, and cross-platform mobile application designs.\r\n\r\n## Phase 3 — Mobile Architecture Patterns\r\n\r\n| Pattern | When to choose |\r\n|---------|---------------|\r\n| MVC | Simple apps, small team, quick prototype |\r\n| MVVM | Data-binding heavy, testable ViewModels needed |\r\n| MVI / Redux (Unidirectional) | Complex state, predictable state transitions, large team |\r\n| Clean Architecture | Long-lived app, multiple teams, strict separation of concerns |\r\n| Modular (feature modules) | Large app, multiple teams, independent feature delivery |\r\n\r\nPlatform-specific defaults:\r\n- **iOS**: MVVM + Combine / SwiftUI, or UIKit + Coordinator\r\n- **Android**: MVVM + Jetpack (ViewModel, LiveData/Flow, Room)\r\n- **Flutter**: BLoC or Riverpod\r\n- **React Native**: Redux Toolkit or Zustand\r\n\r\n## Phase 5 — Critical Flows for Mobile\r\n\r\n1. **App launch flow**: cold start → splash → auth check → deep link / home\r\n2. **Auth flow**: login → token storage → refresh → logout\r\n3. **Data sync flow**: local cache check → stale? → fetch remote → merge → display\r\n4. **Offline flow**: no network → local data → queue mutations → sync on reconnect\r\n5. **Push notification flow**: receive → parse → route → display or background action\r\n\r\n## Phase 6 — Mobile Storage\r\n\r\n| Data type | Storage option | Notes |\r\n|-----------|---------------|-------|\r\n| Structured app data | SQLite (Room, Core Data, sqflite) | |\r\n| User preferences / settings | SharedPreferences / UserDefaults / Hive | |\r\n| Secure credentials / tokens | Keychain (iOS) / Keystore (Android) | Never plain SharedPreferences |\r\n| Media / files | App sandbox file system | |\r\n| Large blobs / remote media | Object storage + local disk cache (with eviction) | |\r\n\r\n## Phase 7 — Mobile-Specific Decision Points\r\n\r\n| Decision | Options | Key differentiator |\r\n|----------|---------|-------------------|\r\n| Native vs cross-platform | Native iOS/Android vs Flutter vs React Native | Team language, performance requirement, platform API depth |\r\n| State management | Local state vs global store | Scope of shared state across screens |\r\n| Offline-first vs online-first | Cache-then-network vs network-only | Network reliability of target environment |\r\n| Image loading | Platform SDKs vs Glide/Picasso/Kingfisher | Cache strategy and memory management |\r\n| API: REST vs GraphQL | REST | GraphQL | Multiple query shapes needed → GraphQL |\r\n\r\n## Phase 8 — Mobile Interface Design\r\n\r\n- **API contract**: same REST/GraphQL standards as web backend, but also define:\r\n  - Pagination (cursor-based recommended for feeds)\r\n  - Partial response (field projection to reduce payload)\r\n  - Offline mutation queue schema (local ID → server ID mapping)\r\n- **Push notifications**: platform (APNs / FCM), payload schema, silent vs user-facing\r\n- **Deep link schema**: URL scheme or universal links, parameter mapping to screens\r\n- **App ↔ native module interface** (React Native / Flutter only): method channel contracts\r\n\r\n## Phase 9 — Mobile Deployment\r\n\r\n| Artifact | Notes |\r\n|----------|-------|\r\n| App binary | iOS: .ipa (App Store / TestFlight); Android: .aab (Play Store) / .apk |\r\n| Signing | iOS: provisioning profile + certificate; Android: keystore |\r\n| Distribution | TestFlight / Firebase App Distribution for beta; App Store / Play Store for production |\r\n| OTA updates | React Native: CodePush; Flutter: not supported for native code |\r\n| CI/CD | Fastlane + GitHub Actions; automate signing, build number bump, upload |\r\n\r\n## Phase 10 — Mobile NFR\r\n\r\n- **App size**: define target APK/IPA size; consider asset compression and code splitting\r\n- **Startup time**: cold start < 2s on median device; measure on low-end device\r\n- **Offline capability**: define which features work offline; which require network\r\n- **Background execution**: battery impact; use Background Fetch / WorkManager constraints\r\n- **Accessibility**: define WCAG 2.1 AA target; test with VoiceOver / TalkBack\r\n- **Crash rate target**: define acceptable crash-free session rate (e.g., ≥ 99.5%)\r\n- **Minimum OS version**: define and document; affects available APIs\n\nFile v1.1.0:specializations/web-backend.md\n\n# Specialization: Web / API Backend\r\n\r\nApply this guidance on top of the base SOP for web services, REST APIs, and microservices.\r\n\r\n## Phase 3 — Architecture Pattern Options\r\n\r\n| Pattern | When to choose |\r\n|---------|---------------|\r\n| Monolith-first | Team < 5, unclear domain boundaries, early product |\r\n| Layered (N-tier) | Well-understood domain, moderate traffic, single team |\r\n| Microservices | Independent scaling requirements, multiple teams, clear domain boundaries |\r\n| Event-driven | High decoupling needed, async-heavy workflows, audit trail required |\r\n| Plugin-based | Extensibility is a first-class requirement (users add algorithms/integrations) |\r\n\r\n## Phase 6 — Storage Selection Rules\r\n\r\n| Data type | Default choice | Escalate when |\r\n|-----------|---------------|---------------|\r\n| Relational business entities | SQLite → PostgreSQL | Need multi-process write, JSONB queries, replication |\r\n| Session / cache / queue | In-process map → Redis | Need persistence across restarts, multi-instance |\r\n| Files / blobs | Local filesystem | Need shared access, CDN, lifecycle policies |\r\n| Search | Database LIKE → Elasticsearch | Full-text, facets, relevance ranking required |\r\n| Time-series metrics | Log files → InfluxDB/TimescaleDB | High-frequency writes, retention policies, aggregations |\r\n\r\n## Phase 7 — Common Decision Points\r\n\r\n| Decision | Option A | Option B | Key differentiator |\r\n|----------|----------|----------|-------------------|\r\n| Sync vs async task execution | Sync HTTP response | Background queue + polling/webhook | Task duration > 5s → use async |\r\n| Monolith vs microservice split | Start monolith | Extract service | Only split when you feel the pain |\r\n| REST vs GraphQL | REST + versioning | GraphQL | Multiple clients with different data needs → GraphQL |\r\n| Auth: session vs token | Server-side session | JWT / OAuth2 token | Stateless horizontal scaling → token |\r\n| Queue: in-process vs broker | In-process queue | Redis / RabbitMQ / Kafka | Durability across restarts required → broker |\r\n\r\n## Phase 8 — API Design Standards\r\n\r\n- Always version: `/api/v1/`\r\n- Use nouns not verbs for resources: `/tasks` not `/getTasks`\r\n- Standard status codes: 200 GET, 201 POST, 204 DELETE, 400 validation, 401 auth, 404 not found, 409 conflict, 422 unprocessable, 500 server error\r\n- Pagination: cursor-based preferred over offset for large datasets\r\n- Error body: `{\"error\": {\"code\": \"RESOURCE_NOT_FOUND\", \"message\": \"...\", \"details\": {}}}`\r\n\r\n## Phase 9 — Deployment Models\r\n\r\n| Model | When to use |\r\n|-------|-------------|\r\n| Single process (no container) | Development only |\r\n| Docker Compose single host | MVP, single-tenant, private deployment |\r\n| Docker Compose + reverse proxy | Small production, < 100 concurrent users |\r\n| Kubernetes | Multi-tenant, auto-scaling, multiple services |\r\n| Serverless (FaaS) | Sporadic traffic, stateless functions, event-driven |\r\n\r\n## Phase 10 — Web-Specific NFR\r\n\r\n- **Rate limiting**: protect all public endpoints; use token bucket or sliding window\r\n- **CORS**: configure explicitly; never use wildcard `*` in production\r\n- **Input validation**: validate and sanitize at the API boundary, not just in business logic\r\n- **SQL injection**: use parameterized queries / ORM only; never string-concatenate SQL\r\n- **Secrets**: never in code or env vars committed to git; use vault or secrets manager\n\nFile v1.1.0:STANDALONE.md\n\n# Software Architecture Design SOP — Standalone Version\r\n\r\n> **使用说明**：将本文件全文复制粘贴给任何 AI（ChatGPT、Claude、Gemini 等），\r\n> 然后说\"请按照上面的 SOP 帮我做架构设计\"，AI 即可执行完整的 12 阶段流程。\r\n> 本文件是 Cursor Skill 的自包含版本，不依赖任何外部文件引用。\r\n\r\n---\r\n\r\n## 架构类型识别（第一步）\r\n\r\n在执行 12 阶段之前，先识别架构类型并加载对应的专项指导（本文末尾）：\r\n\r\n| 类型 | 关键词 | 专项章节 |\r\n|------|--------|---------|\r\n| Web / API 后端 | API、后端、REST、微服务、SaaS | 附录 A |\r\n| ML / AI 系统 | 模型、推理、算法平台、AI、LLM | 附录 B |\r\n| 数据管道 | ETL、数据仓库、Kafka、Spark | 附录 C |\r\n| 嵌入式 / IoT | 嵌入式、固件、MCU、CAN、硬件 | 附录 D |\r\n| 移动端 | iOS、Android、Flutter、React Native | 附录 E |\r\n| 通用 / 混合 | 无明显匹配 | 仅使用基础 SOP |\r\n\r\n---\r\n\r\n## 贯穿全程的核心原则\r\n\r\n- **约束驱动**：每个决策都必须能追溯到一个硬约束（合规、预算、团队、部署环境）\r\n- **决策显式化**：每个非平凡选择都必须展示「方案 A vs 方案 B（选定）+ 理由」\r\n- **MVP 优先**：明确 MVP 边界，v1 不关键的全部延期\r\n- **图表化**：每个主要阶段至少产出一张图，使用 Mermaid 或 PlantUML\r\n- **可执行性**：架构必须能被指定团队用指定技术栈真正构建出来\r\n\r\n---\r\n\r\n## Phase 1 — 需求摄入\r\n\r\n**输入**：需求文档、RFP、PRD、用户故事或口头描述。\r\n\r\n1. 分类所有需求：\r\n   - **功能性**：系统做什么（功能、用户旅程）\r\n   - **非功能性**：性能、可用性 SLA、延迟、吞吐量、数据量\r\n   - **合规/监管**：行业标准、数据驻留、审计要求\r\n   - **部署约束**：离线/内网、云/本地、硬件限制、操作系统\r\n2. 列出前 5 个用户角色及其主要使用场景\r\n3. 记录所有明确的排除项（\"不在范围内\"）\r\n4. 列出歧义和待确认问题，交用户解答后再继续\r\n\r\n---\r\n\r\n## Phase 2 — 系统上下文与边界\r\n\r\n1. 绘制**系统上下文图**（C4 Level 1）：系统作为黑盒 + 外部用户 + 外部系统\r\n\r\n```mermaid\r\nC4Context\r\n  title 系统上下文 — [系统名称]\r\n  Person(user, \"主要用户\", \"用户角色描述\")\r\n  System(system, \"[系统名称]\", \"系统功能描述\")\r\n  System_Ext(extA, \"外部系统 A\", \"提供什么\")\r\n  Rel(user, system, \"使用\", \"HTTPS\")\r\n  Rel(system, extA, \"调用\", \"REST API\")\r\n```\r\n\r\n2. 定义 MVP 交付边界（两张表）：\r\n   - **MVP 包含**：功能 / 类别 / 验收标准\r\n   - **MVP 不包含**：功能 / 计划版本 / 原因\r\n3. 性能目标表：指标 / 目标值 / 测量方法\r\n\r\n---\r\n\r\n## Phase 3 — 分层架构\r\n\r\n1. 选择架构模式并对照 Phase 1 约束说明理由：\r\n   - 可选：分层（N 层）、事件驱动、微服务、插件化、管道过滤器、无服务器、单体优先\r\n2. 定义 3–5 个层次：名称 / 职责 / 关键技术 / 与相邻层的协议\r\n3. 产出**分层架构图**（PlantUML）：\r\n\r\n```plantuml\r\n@startuml\r\ntitle 分层架构 — [系统名称]\r\nrectangle \"展示层\" { component [UI] }\r\nrectangle \"业务层\" { component [核心逻辑] }\r\nrectangle \"数据层\" { component [存储访问] }\r\nrectangle \"基础设施层\" { component [DB / 队列 / 存储] }\r\n[UI] --> [核心逻辑] : HTTP/REST\r\n[核心逻辑] --> [存储访问] : ORM/SDK\r\n@enduml\r\n```\r\n\r\n---\r\n\r\n## Phase 4 — 模块分解\r\n\r\n1. 将每个层次分解为职责单一的模块\r\n2. 绘制**模块依赖图**（有向无环图，不允许循环依赖）：\r\n\r\n```mermaid\r\ngraph TD\r\n  A[模块A] --> B[模块B]\r\n  A --> C[模块C]\r\n  B --> D[共享基础]\r\n  C --> D\r\n```\r\n\r\n3. 每个模块：名称 / 所属层 / 一句话职责 / 关键技术\r\n\r\n---\r\n\r\n## Phase 5 — 核心业务流程\r\n\r\n1. 识别 3–7 个最关键的端到端流程，每个流程产出时序图或流程图：\r\n\r\n```mermaid\r\nsequenceDiagram\r\n  actor 用户\r\n  participant 前端\r\n  participant 后端\r\n  participant DB\r\n  用户->>前端: 操作\r\n  前端->>后端: POST /api/v1/resource\r\n  后端->>DB: 写入\r\n  DB-->>后端: OK\r\n  后端-->>前端: 201 {id}\r\n  alt 错误\r\n    后端-->>前端: 4xx {error}\r\n  end\r\n```\r\n\r\n2. 为所有有状态实体定义**状态机**：\r\n\r\n```mermaid\r\nstateDiagram-v2\r\n  [*] --> 待处理\r\n  待处理 --> 进行中 : 触发条件\r\n  进行中 --> 已完成 : 成功\r\n  进行中 --> 失败 : 错误\r\n  失败 --> 待处理 : 重试\r\n```\r\n\r\n3. 每个流程记录异常处理：哪步失败 → 如何恢复 → 通知谁\r\n\r\n---\r\n\r\n## Phase 6 — 数据架构\r\n\r\n1. 绘制**ER 图**：\r\n\r\n```mermaid\r\nerDiagram\r\n  实体A {\r\n    uuid id PK\r\n    string name\r\n    timestamp created_at\r\n  }\r\n  实体B {\r\n    uuid id PK\r\n    uuid entity_a_id FK\r\n    json metadata\r\n  }\r\n  实体A ||--o{ 实体B : \"拥有\"\r\n```\r\n\r\n2. 存储选型表：数据类型 → 存储组件 → 选型理由\r\n   - 原则：选能满足约束的最简存储，不要过度工程化\r\n3. 关键表结构：字段名 / 类型 / 索引\r\n4. 数据生命周期：保留期限 / 归档策略 / 备份方案\r\n\r\n---\r\n\r\n## Phase 7 — 技术选型\r\n\r\n1. 每个组件类别比较**恰好两个选项**（A vs B 选定）：\r\n\r\n| 维度 | 方案 A | 方案 B（选定） |\r\n|------|--------|--------------|\r\n| 实现复杂度 | | |\r\n| 运维开销 | | |\r\n| 扩展上限 | | |\r\n| 团队熟悉度 | | |\r\n| 约束适配（列出满足/不满足哪条） | | |\r\n| **结论** | | ✓ 选定，原因： |\r\n\r\n2. 技术栈汇总表：类别 / 选型 / 版本 / 选型理由\r\n3. 对照 Phase 1 约束逐项验证\r\n4. 记录故意引入的技术债：\"MVP 选 X，v1.1 迁移到 Y，原因是...\"\r\n\r\n---\r\n\r\n## Phase 8 — 接口设计\r\n\r\n1. **外部 API**：所有端点列表（方法 / 路径 / 用途 / 同步或异步 / 是否需要认证）\r\n2. **扩展接口（SPI）**：若系统可扩展，定义每个扩展必须实现的标准接口\r\n3. **异步协议**：描述 WebSocket、SSE 或消息队列的协议契约\r\n4. **错误响应格式**：标准错误体结构 + 错误码清单\r\n5. **版本策略**：URL 路径版本（`/v1/`）或请求头版本\r\n\r\n---\r\n\r\n## Phase 9 — 部署架构\r\n\r\n1. 绘制**部署拓扑图**（PlantUML）：\r\n\r\n```plantuml\r\n@startuml\r\ntitle 部署拓扑 — [系统名称]\r\nnode \"客户端\" { component [浏览器/App] }\r\nnode \"应用服务器\" { component [API 服务]; component [Worker] }\r\nnode \"数据服务器\" { database [数据库]; storage [对象存储] }\r\n[浏览器/App] --> [API 服务] : HTTPS\r\n[API 服务] --> [数据库] : TCP\r\n[Worker] --> [对象存储] : S3\r\n@enduml\r\n```\r\n\r\n2. 服务器规格表：场景 / 规格 / 说明\r\n3. 所有运行组件：名称 / 职责 / 端口 / 资源要求 / 重启策略\r\n4. **CI/CD 流程**：\r\n\r\n```mermaid\r\nflowchart LR\r\n  A([代码提交]) --> B[静态检查]\r\n  B --> C[单元测试]\r\n  C --> D[构建产物]\r\n  D --> E[集成测试]\r\n  E --> F{分支?}\r\n  F -->|main| G[部署测试环境]\r\n  F -->|tag| H[部署生产环境]\r\n```\r\n\r\n---\r\n\r\n## Phase 10 — 非功能性设计\r\n\r\n必须覆盖以下四个方面：\r\n\r\n| 方面 | 需要说明的内容 |\r\n|------|--------------|\r\n| **高可用** | 每种故障场景：什么失败 / 如何恢复 / RTO 目标 |\r\n| **性能** | 每个 NFR 目标 + 具体实现策略 |\r\n| **安全** | 认证授权模型 / 数据隔离 / 密钥管理 / 审计日志 |\r\n| **可观测性** | MVP 阶段：健康检查接口 + 关键日志；完整阶段：指标 + 告警体系 |\r\n\r\n---\r\n\r\n## Phase 11 — MVP 范围锁定\r\n\r\n1. 最终确认 MVP 包含 / 不包含表（含目标版本）\r\n2. **验收标准**：可量化的\"MVP 完成\"条件\r\n3. 技术债清单：每项债务 + 理由 + 计划偿还版本\r\n\r\n---\r\n\r\n## Phase 12 — 风险登记\r\n\r\n风险表：描述 / 概率（高/中/低）/ 影响（高/中/低）/ 应对措施\r\n\r\n至少包含：\r\n- 依赖风险（第三方库、硬件、外部 API）\r\n- 集成风险（外部系统对接、合规验证）\r\n- 交付风险（范围蔓延、需要 POC 验证的未知项）\r\n\r\n---\r\n\r\n## 输出文档结构\r\n\r\n```\r\n# [项目名] · [系统名] 架构设计文档\r\n\r\n## 1. 文档说明（文档元数据表）\r\n## 2. 项目范围与目标（背景 / MVP 边界 / 系统上下文图 / 性能目标）\r\n## 3. 系统总体架构（架构模式 / 分层图 / 模块图）\r\n## 4. 核心业务流程（时序图 / 流程图 / 状态机 / 异常处理）\r\n## 5. 数据架构（ER 图 / 存储选型 / 表结构 / 生命周期）\r\n## 6. 技术选型与关键决策（选型表 / A vs B 决策表）\r\n## 7. 接口设计（API 表 / SPI 契约 / 错误码）\r\n## 8. 部署与运行架构（部署拓扑图 / 服务器规格 / CI/CD）\r\n## 9. 扩展性设计（插件规范 / 路线图）\r\n## 10. 非功能性设计（HA / 性能 / 安全 / 可观测性）\r\n## 11. 风险、待办与变更记录\r\n```\r\n\r\n---\r\n\r\n# 附录 A — Web / API 后端专项\r\n\r\n**Phase 3 模式选择**：单体优先（团队 < 5）→ 分层 → 微服务（有独立扩展需求时）→ 事件驱动（强解耦、异步为主时）\r\n\r\n**Phase 6 存储升级路径**：\r\n- 关系数据：SQLite → PostgreSQL（多进程写、JSONB 查询、复制时升级）\r\n- 缓存/队列：进程内 → Redis（需跨进程共享、持久化时升级）\r\n- 文件：本地文件系统 → 对象存储（需跨节点共享、CDN 时升级）\r\n\r\n**Phase 8 API 规范**：\r\n- 路径版本：`/api/v1/`\r\n- 资源用名词：`/tasks` 不用 `/getTasks`\r\n- 标准状态码：200/201/204/400/401/404/409/422/500\r\n- 错误体：`{\"error\": {\"code\": \"SNAKE_CASE\", \"message\": \"...\", \"details\": {}}}`\r\n\r\n**Phase 10 安全要点**：\r\n- 所有公开端点加速率限制\r\n- CORS 明确配置，生产不用通配符 `*`\r\n- SQL 全部使用参数化查询 / ORM，禁止字符串拼接\r\n- 密钥不进代码、不进 git，用 vault 或密钥管理服务\r\n\r\n---\r\n\r\n# 附录 B — ML / AI 系统专项\r\n\r\n**Phase 3 标准四层**：\r\n1. 服务 / 应用层（API 网关、用户界面）\r\n2. 编排层（实验追踪、流水线调度、任务队列）\r\n3. 执行 / 计算层（训练 Worker、推理服务器、GPU 调度）\r\n4. 存储 / 注册层（模型注册、特征存储、数据集存储）\r\n\r\n**Phase 5 必须记录的流程**：训练流程 / 推理流程 / 模型晋升流程 / 数据管道流程\r\n\r\n**Phase 6 存储**：\r\n- 模型权重 → 对象存储（版本化、不可变）\r\n- 实验元数据 → 关系型 DB 或 MLflow\r\n- 在线特征 → Redis（低延迟查询）\r\n- 大型数据集 → 对象存储挂载，不复制\r\n\r\n**Phase 8 推理 API 标准**：\r\n```\r\nPOST /v1/predict\r\n{\"model_id\": \"...\", \"inputs\": {...}}\r\n→ {\"prediction\": {...}, \"model_version\": \"1.0\", \"latency_ms\": 42}\r\n\r\nGET /health\r\n→ {\"status\": \"ok\", \"gpu_memory_free_mb\": 8192, \"model_loaded\": true}\r\n```\r\n\r\n**Phase 10 特殊 NFR**：\r\n- 推理延迟定义 P50/P95/P99 分别的目标\r\n- GPU 动态显存调度，不固定串行\r\n- 模型漂移监控：记录输入输出分布，定期检测\r\n- 数据血缘：每个模型版本记录来自哪个数据集版本\r\n\r\n---\r\n\r\n# 附录 C — 数据管道专项\r\n\r\n**Phase 3 模式**：批处理 ETL / 流批一体（Lambda）/ 纯流（Kappa）/ ELT / 湖仓（Medallion）\r\n\r\n**Phase 5 必须记录**：摄入流 / 转换流 / 服务流 / 回填流 / 数据质量检查流\r\n\r\n**Phase 6 分层存储**：\r\n- 原始层（landing）→ 对象存储，不可变\r\n- 清洗层 → Parquet 列式存储\r\n- 策划层 → 数据仓库（ClickHouse、PostgreSQL、BigQuery）\r\n- 服务层 → 列式 DB 或物化视图\r\n\r\n**Phase 10 特殊 NFR**：\r\n- 幂等性：每次运行安全重跑，不产生重复数据\r\n- 数据质量告警：质检失败必须触发告警，不能静默通过\r\n- 数据血缘：每张输出表必须能追溯来源表和转换逻辑版本\r\n\r\n---\r\n\r\n# 附录 D — 嵌入式 / IoT 专项\r\n\r\n**Phase 3 强制分层**：\r\n```\r\n应用逻辑层\r\n    ↓\r\n硬件抽象层（HAL）\r\n    ↓\r\n板级支持包（BSP）/ 驱动\r\n    ↓\r\n物理硬件\r\n```\r\n\r\n**Phase 5 必须记录**：启动初始化流 / 中断服务流 / 通信协议流 / OTA 更新流 / 故障安全流\r\n\r\n**Phase 8 必须定义**：\r\n- 硬件接口：引脚映射、电压、时序、协议帧格式（CAN/UART/SPI）\r\n- 调试接口：日志格式、JTAG/SWD 访问说明\r\n- OTA 接口：包格式、校验和验证、回滚机制\r\n\r\n**Phase 10 特殊 NFR**：\r\n- 实时性：区分硬实时（超时=失败）vs 软实时，定义关键 ISR 最坏执行时间\r\n- 内存预算：每个模块 RAM/Flash 使用上限\r\n- 看门狗：必须由应用层喂狗，禁止在 ISR 中喂\r\n- 失效安全状态：任何未处理错误的确定行为\r\n\r\n---\r\n\r\n# 附录 E — 移动端专项\r\n\r\n**Phase 3 模式**：MVC（简单）→ MVVM（数据绑定）→ MVI/Redux（复杂状态）→ Clean Architecture（大型长期项目）\r\n\r\n**Phase 5 必须记录**：冷启动流 / 认证流 / 数据同步流 / 离线流 / 推送通知流\r\n\r\n**Phase 6 存储**：\r\n- 结构化数据 → SQLite（Room / Core Data / sqflite）\r\n- 凭证 / Token → Keychain（iOS）/ Keystore（Android），禁用 SharedPreferences 存凭证\r\n- 大文件 → 本地磁盘缓存 + 对象存储远端\r\n\r\n**Phase 9 发布产物**：\r\n- iOS：.ipa → TestFlight 测试 → App Store\r\n- Android：.aab → Firebase 测试 → Play Store\r\n- CI/CD：Fastlane + GitHub Actions，自动化签名、版本号、上传\r\n\r\n**Phase 10 特殊 NFR**：\r\n- 冷启动 < 2s（在中低端设备上测量）\r\n- 定义哪些功能离线可用，哪些必须联网\r\n- 崩溃率目标：≥ 99.5% 无崩溃会话\r\n- 定义最低支持 OS 版本\n\nFile v1.1.0:template.md\n\n# Architecture Design Document — Output Template\r\n\r\nUse this chapter structure for every architecture document produced by this skill.\r\nReplace all `[placeholder]` text with actual content.\r\n\r\n---\r\n\r\n```markdown\r\n# [Project Name] · [System Name] 架构设计文档\r\n\r\n---\r\n\r\n## 1. 文档说明\r\n\r\n| 项目 | 内容 |\r\n|------|------|\r\n| **文档名称** | [系统名称] 架构设计文档 |\r\n| **版本号** | V1.0 |\r\n| **创建日期** | [YYYY-MM-DD] |\r\n| **作者** | [作者姓名] |\r\n| **状态** | 草稿 / 评审中 / 已确认 |\r\n| **依据文档** | [需求文档 / 标书 / PRD 名称] |\r\n| **合规标准** | [适用标准，如 ISO/IEC 27001, GB xxx] |\r\n\r\n**文档结构说明**\r\n\r\n| 章节 | 内容 |\r\n|------|------|\r\n| 第 2 章 | 项目范围、交付边界、性能目标 |\r\n| 第 3 章 | 系统总体架构与模块划分 |\r\n| 第 4 章 | 核心业务流程 |\r\n| 第 5 章 | 数据架构 |\r\n| 第 6 章 | 技术选型与关键设计决策 |\r\n| 第 7 章 | 接口设计 |\r\n| 第 8 章 | 部署与运行架构 |\r\n| 第 9 章 | 扩展性设计（插件/SPI/配置） |\r\n| 第 10 章 | 非功能性设计 |\r\n| 第 11 章 | 风险、待办与变更记录 |\r\n\r\n---\r\n\r\n## 2. 项目范围与目标\r\n\r\n### 2.1 项目背景\r\n\r\n[2–3 段说明项目背景、为什么需要这个系统、业务价值]\r\n\r\n### 2.2 交付范围\r\n\r\n**MVP 包含**\r\n\r\n| 类别 | 内容 |\r\n|------|------|\r\n| [功能域] | [具体功能列表] |\r\n\r\n**MVP 不包含**\r\n\r\n| 内容 | 计划版本 | 原因 |\r\n|------|----------|------|\r\n| [功能] | v1.1 | [原因] |\r\n\r\n### 2.3 系统上下文\r\n\r\n![系统上下文图](./diagrams/system-context.png)\r\n\r\n> [一句话说明系统与外部参与者的关系]\r\n\r\n### 2.4 性能目标（MVP）\r\n\r\n| 指标 | 目标值 | 说明 |\r\n|------|--------|------|\r\n| [指标名] | [值] | [测量方法] |\r\n\r\n---\r\n\r\n## 3. 系统总体架构\r\n\r\n### 3.1 架构模式\r\n\r\n[说明选用的架构模式（分层/事件驱动/微服务/插件化），以及选型理由]\r\n\r\n### 3.2 分层架构\r\n\r\n![系统架构图](./diagrams/architecture.png)\r\n\r\n| 层次 | 技术栈 | 职责 |\r\n|------|--------|------|\r\n| **[展示层]** | [技术] | [职责] |\r\n| **[业务层]** | [技术] | [职责] |\r\n| **[执行层]** | [技术] | [职责] |\r\n| **[基础设施层]** | [技术] | [职责] |\r\n\r\n层间通信：[HTTP REST / WebSocket / 消息队列 / gRPC]\r\n\r\n### 3.3 模块划分\r\n\r\n![模块依赖图](./diagrams/module-architecture.png)\r\n\r\n| 层次 | 模块 | 职责 |\r\n|------|------|------|\r\n| [层] | [模块名] | [一句话职责] |\r\n\r\n---\r\n\r\n## 4. 核心业务流程\r\n\r\n### 4.1 [主流程名称]\r\n\r\n![主流程时序图](./diagrams/main-flow.png)\r\n\r\n**状态机**：[状态A] → [状态B] → [状态C / 状态D（异常）]\r\n\r\n**异常处理**\r\n\r\n| 场景 | 处理策略 |\r\n|------|----------|\r\n| [异常场景] | [处理方式] |\r\n\r\n### 4.2 [次流程名称]\r\n\r\n![次流程图](./diagrams/sub-flow.png)\r\n\r\n> [流程说明]\r\n\r\n---\r\n\r\n## 5. 数据架构\r\n\r\n### 5.1 核心实体关系\r\n\r\n![ER 图](./diagrams/er-diagram.png)\r\n\r\n### 5.2 存储选型\r\n\r\n| 存储组件 | 存储内容 | 选型理由 |\r\n|----------|----------|----------|\r\n| [组件] | [内容] | [理由] |\r\n\r\n### 5.3 核心数据实体\r\n\r\n| 实体 | 主要字段 | 说明 |\r\n|------|----------|------|\r\n| [表名] | [字段列表] | [说明] |\r\n\r\n---\r\n\r\n## 6. 技术选型与关键设计决策\r\n\r\n### 6.1 技术选型\r\n\r\n| 类别 | 选型 | 版本 | 说明 |\r\n|------|------|------|------|\r\n| [类别] | [技术] | [版本] | [选型理由] |\r\n\r\n### 6.2 关键设计决策\r\n\r\n| 决策点 | 方案 A | 方案 B（选定） | 理由 |\r\n|--------|--------|---------------|------|\r\n| [决策点] | [方案A] | [方案B] | [理由] |\r\n\r\n---\r\n\r\n## 7. 接口设计\r\n\r\n### 7.1 平台 API\r\n\r\n**[功能模块] 接口**\r\n\r\n| 接口 | 方法 | 路径 | 说明 |\r\n|------|------|------|------|\r\n| [接口名] | GET/POST | `/api/v1/[path]` | [说明] |\r\n\r\n### 7.2 扩展接口契约（SPI）\r\n\r\n[如果系统有插件/扩展机制，在此定义标准接口]\r\n\r\n| 接口 | 方法 | 路径 | 说明 |\r\n|------|------|------|------|\r\n| 健康检查 | GET | `/health` | 含资源信息 |\r\n\r\n---\r\n\r\n## 8. 部署与运行架构\r\n\r\n### 8.1 部署拓扑\r\n\r\n![部署拓扑图](./diagrams/deployment.png)\r\n\r\n### 8.2 服务器规格\r\n\r\n| 场景 | 规格 | 说明 |\r\n|------|------|------|\r\n| 最低配置 | [CPU / RAM / 存储] | [说明] |\r\n| 推荐配置 | [CPU / RAM / 存储] | [说明] |\r\n\r\n### 8.3 服务组成\r\n\r\n| 服务 | 说明 | 端口 | 重启策略 |\r\n|------|------|------|----------|\r\n| [服务名] | [说明] | [端口] | always |\r\n\r\n### 8.4 CI/CD 流程\r\n\r\n![CI/CD 流程图](./diagrams/cicd.png)\r\n\r\n> [触发条件] → [构建步骤] → [测试] → [发布]\r\n\r\n---\r\n\r\n## 9. 扩展性设计\r\n\r\n### 9.1 [扩展点名称]\r\n\r\n[描述插件/配置/SPI 的规范，使用者如何扩展系统]\r\n\r\n### 9.2 扩展路线图\r\n\r\n![扩展路线图](./diagrams/roadmap.png)\r\n\r\n---\r\n\r\n## 10. 非功能性设计\r\n\r\n### 10.1 高可用\r\n\r\n| 故障场景 | 处理策略 |\r\n|----------|----------|\r\n| [故障] | [策略] |\r\n\r\n### 10.2 性能指标\r\n\r\n| 目标 | 指标 |\r\n|------|------|\r\n| [指标名] | [目标值] |\r\n\r\n### 10.3 安全性\r\n\r\n| 类别 | 设计 |\r\n|------|------|\r\n| 认证 | [方案] |\r\n| 数据隔离 | [方案] |\r\n| 审计日志 | [方案] |\r\n\r\n### 10.4 可观测性\r\n\r\n[MVP 阶段的监控接口；完整阶段的 Prometheus/Grafana 指标]\r\n\r\n---\r\n\r\n## 11. 风险、待办与变更记录\r\n\r\n### 11.1 风险与应对\r\n\r\n| 风险 | 概率 | 影响 | 应对措施 |\r\n|------|------|------|----------|\r\n| [风险描述] | 高/中/低 | 高/中/低 | [措施] |\r\n\r\n### 11.2 待办事项\r\n\r\n- [ ] [待确认事项]\r\n- [ ] [待 POC 验证事项]\r\n\r\n### 11.3 变更记录\r\n\r\n| 版本 | 日期 | 作者 | 变更内容 |\r\n|------|------|------|----------|\r\n| V1.0 | [日期] | [作者] | 初稿 |\r\n\r\n---\r\n\r\n*[项目名] · 依据：[需求文档] · 合规：[标准]*\r\n```","readmeExcerpt":"Skill: Software Architecture Design SOP Owner: 1231111 Summary: Produces a complete software architecture design document following a 12-phase SOP. Supports web backend, mobile, ML/AI, data pipeline, embedded/IoT. Generat... Tags: architecture:1.1.0, latest:1.1.0, mermaid:1.1.0, plantuml:1.1.0, sop:1.1.0, system-design:1.1.0 Version history: v1.1.0 | 2026-05-28T03:01:16.413Z | user Initial public release: 12-phase SO","codeSnippets":[],"executableExamples":[],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\r\nname: software-architecture-design\r\nversion: 1.1.0\r\nauthor: sunbinbin\r\nlicense: MIT\r\ntags: architecture, system-design, technical-design, sop, mermaid, plantuml, web, mobile, ml, embedded, data-pipeline\r\ndescription: \"Produces a complete software architecture design document following a 12-phase SOP. Supports web backend, mobile, ML/AI, data pipeline, embedded/IoT. Generates Mermaid and PlantUML diagrams. Use when asked to do architecture design, system design, technical design, or says: 做架构设计 系统设计 技术方案 架构文档.\"\r\nmetadata: {\"openclaw\": {\"emoji\": \"🏗️\", \"os\": [\"darwin\", \"linux\", \"win32\"]}}\r\n---\r\n\r\n# Software Architecture Design SOP\r\n\r\n## Step 0 — Identify Architecture Type First\r\n\r\nBefore starting the 12 phases, identify the architecture type and load the matching specialization:\r\n\r\n| Type | Trigger keywords | Specialization file |\r\n|------|-----------------|---------------------|\r\n| Web / API backend | API, 后端, 服务端, REST, 微服务, SaaS | `{baseDir}/specializations/web-backend.md` |\r\n| ML / AI system | 模型, 推理, 训练, 算法平台, AI, LLM | `{baseDir}/specializations/ml-system.md` |\r\n| Data pipeline | ETL, 数据仓库, 数据湖, Kafka, Spark | `{baseDir}/specializations/data-pipeline.md` |\r\n| Embedded / IoT | 嵌入式, 固件, MCU, RTOS, 硬件, CAN | `{baseDir}/specializations/embedded.md` |\r\n| Mobile app | iOS, Android, Flutter, React Native | `{baseDir}/specializations/mobile.md` |\r\n| General / Mixed | (none of the above match clearly) | Use base SOP only |\r\n\r\nRead the matched specialization file for domain-specific guidance on Phases 3, 6, 7, 9.\r\n\r\n---\r\n\r\n## Core Principles (apply throughout)\r\n\r\n- **Constraint-driven** — Every decision traces back to a hard constraint (compliance, budget, team, deployment env).\r\n- **Decision explicit** — For every non-trivial choice, show Option A vs Option B and the reason for selection.\r\n- **MVP-first** — Define a clear MVP boundary. Defer everything not critical to v1.\r\n- **Diagram every concept** — Each major phase produces at least one diagram (see diagram guide in `{baseDir}/reference.md`).\r\n- **Executable** — The architecture must be buildable by the stated team with the stated tech stack.\r\n\r\n---\r\n\r\n## Phase 1 — Requirement Intake\r\n\r\n**Input**: Requirements doc, RFP, PRD, user stories, or verbal description.\r\n\r\n1. Classify all requirements:\r\n   - **Functional** — what the system does (features, user journeys)\r\n   - **Non-functional** — performance, availability SLA, latency, throughput, data volume\r\n   - **Compliance / regulatory** — industry standards, data residency, audit requirements\r\n   - **Deployment constraints** — air-gap, on-prem, cloud, edge, hardware limits, OS\r\n2. List the top 5 user roles and their primary use cases.\r\n3. Capture all explicit exclusions (\"out of scope\").\r\n4. List open questions / ambiguities — ask the user to resolve before proceeding.\r\n\r\n---\r\n\r\n## Phase 2 — System Context & Boundary\r\n\r\n1. Draw **System Context Diagram** (C4 Level 1): system as a black box + external actors + external systems.\r\n2. Define MVP de"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn7fp5s80ck78fqh36fht9sdcd87jhp9\",\n  \"slug\": \"software-architecture-design\",\n  \"version\": \"1.1.0\",\n  \"publishedAt\": 1779937276413\n}"},{"path":"reference.md","content":"# Architecture Design — Reference\r\n\r\n## Phase-by-Phase Checklist\r\n\r\n### Phase 1: Requirement Intake\r\n- [ ] All source documents read in full\r\n- [ ] Functional requirements listed and numbered\r\n- [ ] Non-functional: performance, availability, latency, throughput, data volume\r\n- [ ] Compliance standards identified (ISO, GDPR, HIPAA, GB, IEC, etc.)\r\n- [ ] Deployment constraints captured (air-gap, GPU, OS, cloud/on-prem, hardware)\r\n- [ ] Top 5 user roles and use cases written\r\n- [ ] Open questions listed for user to resolve\r\n\r\n### Phase 2: System Context & Boundary\r\n- [ ] System Context Diagram exists with all external actors and systems labeled\r\n- [ ] MVP Includes table with success criteria per feature\r\n- [ ] MVP Excludes table with target version per exclusion\r\n- [ ] Performance targets table with measurement method\r\n\r\n### Phase 3: Layered Architecture\r\n- [ ] Architecture pattern named and justified against constraints\r\n- [ ] Every layer: name / stack / responsibility / inter-layer protocol\r\n- [ ] Layer architecture diagram exists\r\n\r\n### Phase 4: Module Decomposition\r\n- [ ] Every module: one-sentence responsibility\r\n- [ ] No circular dependencies (verified)\r\n- [ ] Module dependency diagram exists (DAG)\r\n\r\n### Phase 5: Core Business Flows\r\n- [ ] At least 3 critical flows documented with diagrams\r\n- [ ] State machines for all stateful entities\r\n- [ ] Exception paths documented per flow\r\n\r\n### Phase 6: Data Architecture\r\n- [ ] ER diagram covering all core entities\r\n- [ ] Storage selection justified per data type\r\n- [ ] Key schemas with field names and types\r\n- [ ] Backup / retention policy stated\r\n\r\n### Phase 7: Technology Selection\r\n- [ ] Option A vs Option B table for each component\r\n- [ ] Each selection validated against Phase 1 constraints\r\n- [ ] No orphaned technologies (every tech appears in the architecture)\r\n- [ ] Deliberate tech debt documented with rationale\r\n\r\n### Phase 8: Interface Design\r\n- [ ] All endpoints in a table (method, path, purpose, sync/async, auth)\r\n- [ ] SPI/plugin contract defined if extensibility required\r\n- [ ] Async protocol (WebSocket / SSE / queue) described\r\n- [ ] Error response schema defined\r\n- [ ] Versioning strategy stated\r\n\r\n### Phase 9: Deployment Architecture\r\n- [ ] Deployment topology diagram exists\r\n- [ ] Server/hardware specs for min / recommended / production\r\n- [ ] All runtime components with ports and resource requirements\r\n- [ ] Volume / filesystem / data flow described\r\n- [ ] CI/CD pipeline steps listed\r\n\r\n### Phase 10: Non-Functional Design\r\n- [ ] HA: failure scenarios and recovery strategies\r\n- [ ] Performance: each metric + implementation strategy\r\n- [ ] Security: auth, secrets, data isolation, audit\r\n- [ ] Observability: MVP health endpoints + future metrics plan\r\n\r\n### Phase 11: MVP Scope Lock\r\n- [ ] MVP Includes / Excludes finalized\r\n- [ ] Success criteria measurable\r\n- [ ] Tech debt register complete\r\n\r\n### Phase 12: Risk Register\r\n- [ ] ≥ 5 risks documented\r\n- [ ] Each risk: probability + impact"},{"path":"skill-card.md","content":"## Description:\n\nProduces complete software architecture design documents through a 12-phase SOP for web backend, mobile, ML/AI, data pipeline, and embedded/IoT systems, with Mermaid and PlantUML diagram guidance.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[1231111](https://clawhub.ai/user/1231111)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and engineers use this skill to turn requirements, PRDs, RFPs, or verbal system descriptions into structured architecture design documents with MVP scope, architecture decisions, interfaces, deployment, non-functional design, and risk registers.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Generated ML/AI architecture guidance may include detailed health endpoints that expose resource status if copied directly into production designs.\n\nMitigation: Keep public liveness checks minimal and move detailed health and resource reporting to authenticated internal metrics endpoints before production use.\n\nRisk: The default output template is Chinese, which may not match every team's documentation language.\n\nMitigation: Ask the agent for the required output language at the start of the architecture-design request.\n\nRisk: Architecture proposals can be incomplete or misaligned when requirements are ambiguous.\n\nMitigation: Resolve the Phase 1 open questions and review generated decisions, diagrams, and risk registers with domain owners before adoption.\n\n## Reference(s):\n\n- [Architecture Design Reference](artifact/reference.md)\n- [Architecture Design Document Template](artifact/template.md)\n- [Standalone Software Architecture Design SOP](artifact/STANDALONE.md)\n- [Web / API Backend Specialization](artifact/specializations/web-backend.md)\n- [ML / AI System Specialization](artifact/specializations/ml-system.md)\n- [Data Pipeline / Data Platform Specialization](artifact/specializations/data-pipeline.md)\n- [Embedded / IoT System Specialization](artifact/specializations/embedded.md)\n- [Mobile App Specialization](artifact/specializations/mobile.md)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Code, Guidance]\n\n**Output Format:** [Markdown architecture document with Mermaid and PlantUML code blocks]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Default output template is Chinese unless the user asks for another language.]\n\n## Skill Version(s):\n\n1.1.0 (source: frontmatter and server release metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment."},{"path":"specializations/data-pipeline.md","content":"# Specialization: Data Pipeline / Data Platform\r\n\r\nApply this guidance for ETL, ELT, data warehouse, data lake, streaming, and analytics platform designs.\r\n\r\n## Phase 3 — Data Pipeline Architecture Patterns\r\n\r\n| Pattern | When to choose |\r\n|---------|---------------|\r\n| Batch ETL | Latency tolerance hours/days; large volume; simple transforms |\r\n| Streaming (Lambda) | Real-time + batch coexist; complex state management |\r\n| Streaming-only (Kappa) | All processing as streams; late data handled by reprocessing |\r\n| ELT (load first, transform in warehouse) | Cloud DW available; raw data preservation needed |\r\n| Medallion (Bronze/Silver/Gold) | Data lake; incremental quality improvement; multiple consumer types |\r\n\r\n## Phase 5 — Critical Flows for Data Pipelines\r\n\r\n1. **Ingestion flow**: source → extract → validate → land (raw)\r\n2. **Transform flow**: raw → clean → enrich → aggregate\r\n3. **Serving flow**: aggregated data → query engine → consumer (BI, API, ML)\r\n4. **Backfill / reprocessing flow**: historical data re-ingestion on schema/logic change\r\n5. **Data quality check flow**: record → validation rules → quarantine or pass\r\n\r\n## Phase 6 — Storage Layers\r\n\r\n| Layer | Purpose | Technology options |\r\n|-------|---------|-------------------|\r\n| Landing (raw) | Exact copy of source, immutable | Object storage (S3/MinIO), file system |\r\n| Staging | Cleaned, typed, deduplicated | Parquet on object storage |\r\n| Curated | Business-ready aggregates | Data warehouse (PostgreSQL, ClickHouse, BigQuery) |\r\n| Serving | Low-latency query | Columnar DB, materialized views, Redis cache |\r\n| Metadata | Lineage, schema, quality stats | Relational DB (PostgreSQL) |\r\n\r\n## Phase 7 — Data Pipeline Decision Points\r\n\r\n| Decision | Key question | Options |\r\n|----------|-------------|---------|\r\n| Batch vs stream | What is the acceptable latency? | minutes → micro-batch; seconds → streaming |\r\n| Orchestration | How many pipelines? Complex dependencies? | Cron → Airflow → Prefect/Dagster |\r\n| Transform engine | Data volume? Team language? | SQL (dbt) vs Python (Spark/Pandas) vs Beam |\r\n| Messaging | Throughput and durability? | Redis Streams → RabbitMQ → Kafka |\r\n| Schema management | Schema evolution needed? | None → JSON Schema → Avro/Protobuf |\r\n\r\n## Phase 8 — Data Pipeline Interface Design\r\n\r\nDefine these contracts explicitly:\r\n\r\n- **Source connectors**: protocol, auth, extraction mode (full / incremental / CDC), rate limits\r\n- **Schema registry**: where schemas are defined, how consumers discover them\r\n- **Data quality contract**: which fields are required, valid ranges, uniqueness constraints\r\n- **SLA contract**: ingestion frequency, max latency, freshness guarantee\r\n\r\n## Phase 9 — Deployment Patterns\r\n\r\n| Pattern | Scale | Notes |\r\n|---------|-------|-------|\r\n| Single server + cron | Small, < 10 pipelines | Simple, low ops overhead |\r\n| Docker Compose + Airflow | Medium, < 100 pipelines | Managed scheduling |\r\n| Kubernetes + Helm | Large, 100+ pipelines, multi-tenant "}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"Produces a complete software architecture design document following a 12-phase SOP. Supports web backend, mobile, ML/AI, data pipeline, embedded/IoT. Generat... Skill: Software Architecture Design SOP Owner: 1231111 Summary: Produces a complete software architecture design document following a 12-phase SOP. Supports web backend, mobile, ML/AI, data pipeline, embedded/IoT. Generat... Tags: architecture:1.1.0, latest:1.1.0, mermaid:1.1.0, plantuml:1.1.0, sop:1.1.0, system-design:1.1.0 Version history: v1.1.0 | 2026-05-28T03:01:16.413Z | user Initial public release: 12-phase SO","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1762,"uniquenessScore":50,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T07:07:53.517Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T07:07:53.517Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-11T10:51:16.047Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}