@bcelep/capint 0.4.2 → 0.6.5

package/skills/deprecation-and-migration/SKILL.md

@@ -0,0 +1,206 @@
+---
+name: deprecation-and-migration
+description: Manages deprecation and migration. Use when removing old systems, APIs, or features. Use when migrating users from one implementation to another. Use when deciding whether to maintain or sunset existing code.
+---
+
+# Deprecation and Migration
+
+## Overview
+
+Code is a liability, not an asset. Every line of code has ongoing maintenance cost — bugs to fix, dependencies to update, security patches to apply, and new engineers to onboard. Deprecation is the discipline of removing code that no longer earns its keep, and migration is the process of moving users safely from the old to the new.
+
+Most engineering organizations are good at building things. Few are good at removing them. This skill addresses that gap.
+
+## When to Use
+
+- Replacing an old system, API, or library with a new one
+- Sunsetting a feature that's no longer needed
+- Consolidating duplicate implementations
+- Removing dead code that nobody owns but everybody depends on
+- Planning the lifecycle of a new system (deprecation planning starts at design time)
+- Deciding whether to maintain a legacy system or invest in migration
+
+## Core Principles
+
+### Code Is a Liability
+
+Every line of code has ongoing cost: it needs tests, documentation, security patches, dependency updates, and mental overhead for anyone working nearby. The value of code is the functionality it provides, not the code itself. When the same functionality can be provided with less code, less complexity, or better abstractions — the old code should go.
+
+### Hyrum's Law Makes Removal Hard
+
+With enough users, every observable behavior becomes depended on — including bugs, timing quirks, and undocumented side effects. This is why deprecation requires active migration, not just announcement. Users can't "just switch" when they depend on behaviors the replacement doesn't replicate.
+
+### Deprecation Planning Starts at Design Time
+
+When building something new, ask: "How would we remove this in 3 years?" Systems designed with clean interfaces, feature flags, and minimal surface area are easier to deprecate than systems that leak implementation details everywhere.
+
+## The Deprecation Decision
+
+Before deprecating anything, answer these questions:
+
+```
+1. Does this system still provide unique value?
+   → If yes, maintain it. If no, proceed.
+
+2. How many users/consumers depend on it?
+   → Quantify the migration scope.
+
+3. Does a replacement exist?
+   → If no, build the replacement first. Don't deprecate without an alternative.
+
+4. What's the migration cost for each consumer?
+   → If trivially automated, do it. If manual and high-effort, weigh against maintenance cost.
+
+5. What's the ongoing maintenance cost of NOT deprecating?
+   → Security risk, engineer time, opportunity cost of complexity.
+```
+
+## Compulsory vs Advisory Deprecation
+
+| Type | When to Use | Mechanism |
+|------|-------------|-----------|
+| **Advisory** | Migration is optional, old system is stable | Warnings, documentation, nudges. Users migrate on their own timeline. |
+| **Compulsory** | Old system has security issues, blocks progress, or maintenance cost is unsustainable | Hard deadline. Old system will be removed by date X. Provide migration tooling. |
+
+**Default to advisory.** Use compulsory only when the maintenance cost or risk justifies forcing migration. Compulsory deprecation requires providing migration tooling, documentation, and support — you can't just announce a deadline.
+
+## The Migration Process
+
+### Step 1: Build the Replacement
+
+Don't deprecate without a working alternative. The replacement must:
+
+- Cover all critical use cases of the old system
+- Have documentation and migration guides
+- Be proven in production (not just "theoretically better")
+
+### Step 2: Announce and Document
+
+```markdown
+## Deprecation Notice: OldService
+
+**Status:** Deprecated as of 2025-03-01
+**Replacement:** NewService (see migration guide below)
+**Removal date:** Advisory — no hard deadline yet
+**Reason:** OldService requires manual scaling and lacks observability.
+            NewService handles both automatically.
+
+### Migration Guide
+1. Replace `import { client } from 'old-service'` with `import { client } from 'new-service'`
+2. Update configuration (see examples below)
+3. Run the migration verification script: `npx migrate-check`
+```
+
+### Step 3: Migrate Incrementally
+
+Migrate consumers one at a time, not all at once. For each consumer:
+
+```
+1. Identify all touchpoints with the deprecated system
+2. Update to use the replacement
+3. Verify behavior matches (tests, integration checks)
+4. Remove references to the old system
+5. Confirm no regressions
+```
+
+**The Churn Rule:** If you own the infrastructure being deprecated, you are responsible for migrating your users — or providing backward-compatible updates that require no migration. Don't announce deprecation and leave users to figure it out.
+
+### Step 4: Remove the Old System
+
+Only after all consumers have migrated:
+
+```
+1. Verify zero active usage (metrics, logs, dependency analysis)
+2. Remove the code
+3. Remove associated tests, documentation, and configuration
+4. Remove the deprecation notices
+5. Celebrate — removing code is an achievement
+```
+
+## Migration Patterns
+
+### Strangler Pattern
+
+Run old and new systems in parallel. Route traffic incrementally from old to new. When the old system handles 0% of traffic, remove it.
+
+```
+Phase 1: New system handles 0%, old handles 100%
+Phase 2: New system handles 10% (canary)
+Phase 3: New system handles 50%
+Phase 4: New system handles 100%, old system idle
+Phase 5: Remove old system
+```
+
+### Adapter Pattern
+
+Create an adapter that translates calls from the old interface to the new implementation. Consumers keep using the old interface while you migrate the backend.
+
+```typescript
+// Adapter: old interface, new implementation
+class LegacyTaskService implements OldTaskAPI {
+  constructor(private newService: NewTaskService) {}
+
+  // Old method signature, delegates to new implementation
+  getTask(id: number): OldTask {
+    const task = this.newService.findById(String(id));
+    return this.toOldFormat(task);
+  }
+}
+```
+
+### Feature Flag Migration
+
+Use feature flags to switch consumers from old to new system one at a time:
+
+```typescript
+function getTaskService(userId: string): TaskService {
+  if (featureFlags.isEnabled('new-task-service', { userId })) {
+    return new NewTaskService();
+  }
+  return new LegacyTaskService();
+}
+```
+
+## Zombie Code
+
+Zombie code is code that nobody owns but everybody depends on. It's not actively maintained, has no clear owner, and accumulates security vulnerabilities and compatibility issues. Signs:
+
+- No commits in 6+ months but active consumers exist
+- No assigned maintainer or team
+- Failing tests that nobody fixes
+- Dependencies with known vulnerabilities that nobody updates
+- Documentation that references systems that no longer exist
+
+**Response:** Either assign an owner and maintain it properly, or deprecate it with a concrete migration plan. Zombie code cannot stay in limbo — it either gets investment or removal.
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "It still works, why remove it?" | Working code that nobody maintains accumulates security debt and complexity. Maintenance cost grows silently. |
+| "Someone might need it later" | If it's needed later, it can be rebuilt. Keeping unused code "just in case" costs more than rebuilding. |
+| "The migration is too expensive" | Compare migration cost to ongoing maintenance cost over 2-3 years. Migration is usually cheaper long-term. |
+| "We'll deprecate it after we finish the new system" | Deprecation planning starts at design time. By the time the new system is done, you'll have new priorities. Plan now. |
+| "Users will migrate on their own" | They won't. Provide tooling, documentation, and incentives — or do the migration yourself (the Churn Rule). |
+| "We can maintain both systems indefinitely" | Two systems doing the same thing is double the maintenance, testing, documentation, and onboarding cost. |
+
+## Red Flags
+
+- Deprecated systems with no replacement available
+- Deprecation announcements with no migration tooling or documentation
+- "Soft" deprecation that's been advisory for years with no progress
+- Zombie code with no owner and active consumers
+- New features added to a deprecated system (invest in the replacement instead)
+- Deprecation without measuring current usage
+- Removing code without verifying zero active consumers
+
+## Verification
+
+After completing a deprecation:
+
+- [ ] Replacement is production-proven and covers all critical use cases
+- [ ] Migration guide exists with concrete steps and examples
+- [ ] All active consumers have been migrated (verified by metrics/logs)
+- [ ] Old code, tests, documentation, and configuration are fully removed
+- [ ] No references to the deprecated system remain in the codebase
+- [ ] Deprecation notices are removed (they served their purpose)

package/skills/design-reviewer/SKILL.md

@@ -0,0 +1,189 @@
+---
+name: design-reviewer
+description: 使用三维框架（系统设计、运行模拟、工程实现）系统性审查架构 and 系统设计文档，作为 challenge 工作流中的规范契约设计证据层。产出按严重度分级的发现，关联 to 具体文档段落。
+---
+
+# 设计审查大师手册
+
+> "代码之前发现的设计缺陷，能省下一百个 Bug。  
+> 对设计严厉，代码才能优雅。"
+
+你是**设计审查大师**，负责系统性审查架构和系统设计文档。你的三维框架确保没有任何一类风险被遗漏。
+在 `/challenge` 工作流中，你的角色是：**为规范契约是否闭合提供设计侧证据**，而不是单独给出脱离上下文的最终裁决。
+你优先要证明的是：哪些契约在**系统边界、接口、状态、时序、错误路径**上没有闭合。
+
+---
+
+## 任务目标
+
+1. **加载文档 (必须)**: 读取 `ARCHITECTURE.md`、所有 `SYSTEM_DESIGN/*.md` 以及所有 `ADR/*.md`。
+2. **深度理解**: 使用 `sequential-thinking` skill（3-5 个 thought）在批判之前先理解设计意图。
+3. **Pre-Mortem**: 想象项目在 6 个月后失败了——倒推根因。
+4. **三维审查**: 系统性执行全部 3 个维度。
+5. **假设验证**: 识别隐藏假设并尝试证伪。
+6. **生成发现**: 为每条发现标注严重度，并关联到具体文档段落。
+
+## 硬约束
+
+- **证据为本**: 每条发现**必须**有具体文档引用 + 推理链。"可能有性能问题"这种没有分析的说法禁止出现。
+- **质量优于数量**: 3 条真实发现 > 10 条猜测。
+- **尊重 ADR 决策**: 如果 ADR 明确选择了某个权衡并附有文档化的理由，不要翻旧账。仅在出现新证据反驳原有理由时才标记。
+- **不涉及实现细节**: 审查的是*设计*，不是假想的代码。
+
+---
+
+## 三维审查框架
+
+### 维度 1: 系统设计 (System Design)
+
+**目标**: 验证架构的完整性、一致性和边界清晰度。
+
+
+| #    | 检查项         | 关注要点                                           |
+| ---- | ----------- | ---------------------------------------------- |
+| SD-1 | **架构一致性**   | 同一组件在 PRD、Architecture、System Design 中的描述是否矛盾？ |
+| SD-2 | **边界清晰度**   | 每个系统的职责范围是否明确？是否存在职责重叠？                        |
+| SD-3 | **依赖合理性**   | 系统依赖是否无环？是否存在隐藏耦合？                             |
+| SD-4 | **接口完整性**   | 所有跨系统接口是否完整定义（输入/输出/错误/协议）？                    |
+| SD-5 | **状态管理**    | 系统状态转换是否清晰定义？边缘状态是否处理？                         |
+| SD-6 | **数据模型完整性** | 实体关系是否跨文档一致？是否存在孤儿实体？                          |
+
+
+**思考提示**（配合 `sequential-thinking` 使用）:
+
+1. "这个架构背后的核心假设是什么？"
+2. "如果假设 X 不成立，什么会崩？"
+3. "系统边界定义是否存在歧义？"
+4. "接口是否覆盖了所有边界情况？"
+
+---
+
+### 维度 2: 运行模拟 (Runtime Simulation)
+
+**目标**: 在脑中"运行"系统，发现时序、状态和并发问题。
+
+> 本维度**必须**使用 `sequential-thinking` skill（3-5 个 thought）。运行时问题藏在序列中。
+
+
+| #    | 检查项               | 关注要点                           |
+| ---- | ----------------- | ------------------------------ |
+| RS-1 | **时序一致性**         | 时序模型是否合理？是否存在"必须先于"的矛盾？        |
+| RS-2 | **状态同步**          | 分布式状态下，副本是否可能发散？最终一致性在这里是否可接受？ |
+| RS-3 | **并发处理**          | 两个操作冲突时会怎样？是否有解决策略？            |
+| RS-4 | **边界条件**          | 空状态、满状态、溢出——各自如何处理？            |
+| RS-5 | **故障传播**          | 组件 A 故障时如何影响 B、C？是否存在级联风险？     |
+| RS-6 | **Happy Path 偏见** | 只设计了正常路径？错误/超时/部分失败路径呢？        |
+
+
+**思考提示**:
+
+1. "端到端追踪一个典型操作，经过哪些步骤？"
+2. "每一步产生什么状态变更？什么可能出错？"
+3. "如果两个用户同时做同一件事会怎样？"
+4. "崩溃后 30 秒，系统是什么样子？"
+
+---
+
+### 维度 3: 工程实现 (Engineering Implementation)
+
+**目标**: 验证设计可构建、可测试、可维护。
+
+> 本维度**必须**使用 `sequential-thinking` skill（3-5 个 thought）。
+
+
+| #    | 检查项        | 关注要点                         |
+| ---- | ---------- | ---------------------------- |
+| EI-1 | **可测试性**   | 核心逻辑能否被单元测试？是否有 Mock 的接缝？    |
+| EI-2 | **可维护性**   | 如果需求变更，需要改多少文件？              |
+| EI-3 | **性能瓶颈**   | 设计中是否隐藏了 N+1 查询、无界循环或 O(n²)？ |
+| EI-4 | **安全面**    | 认证边界是否清晰？敏感数据静态/传输加密？输入校验？   |
+| EI-5 | **可观测性**   | 凭设计中的日志/指标方案能否调试生产问题？        |
+| EI-6 | **技术栈契合度** | 选定的技术是否真正支持所需功能？版本兼容性？       |
+
+
+**思考提示**:
+
+1. "如何为核心逻辑写单元测试？"
+2. "如果需要修改功能 X，影响范围多大？"
+3. "性能热点在哪？能否后续优化？"
+4. "这个设计暴露了哪些攻击向量？"
+
+---
+
+## 严重度分级
+
+
+| 等级           | 判定标准                 | 所需行动                          |
+| ------------ | -------------------- | ----------------------------- |
+| **Critical** | 根本性矛盾或不可能实现。不解决无法继续。 | P0 — 必须在 blueprint/forge 之前修复 |
+| **High**     | 大概率导致返工或失败的严重风险。     | P1 — 在 forge 之前修复             |
+| **Medium**   | 有变通方案的质量隐患。          | P2 — 实现阶段修复                   |
+| **Low**      | 润色项或轻微不一致。           | P3 — 后续跟踪                     |
+
+
+---
+
+## 输出格式
+
+按以下结构生成发现，适合纳入 `07_CHALLENGE_REPORT.md`：
+
+```markdown
+## 设计审查发现
+
+### 摘要
+
+| 维度 | 发现数 | Critical | High | Medium | Low |
+|------|:------:|:--------:|:----:|:------:|:---:|
+| 系统设计 | — | — | — | — | — |
+| 运行模拟 | — | — | — | — | — |
+| 工程实现 | — | — | — | — | — |
+| **合计** | **—** | **—** | **—** | **—** | **—** |
+
+**高信号结论**: [用 1-3 句概括最值得进入 challenge 主报告的问题]
+
+---
+
+### 核心发现清单
+
+| ID | 维度 | 严重度 | 文档位置 | 发现 | 影响 | 建议 |
+|----|------|--------|----------|------|------|------|
+| DR-01 | 系统设计 | Critical | ARCHITECTURE.md §X | 边界定义冲突，两个系统职责重叠 | 实现阶段职责漂移、返工风险高 | 重新划清系统边界并更新引用 |
+| DR-02 | 运行模拟 | High | SYSTEM_DESIGN/... §Y | 故障传播路径未定义 | 级联失败时无法收敛 | 增加超时/降级/重试策略 |
+| DR-03 | 工程实现 | Medium | ADR-00X / System Design §Z | 可测试接缝不足 | 后续验证成本高 | 增加接口隔离或 mock 接缝 |
+
+> 仅输出真正影响设计判断的问题。低价值措辞、重复担忧不要进入清单。
+
+---
+
+### Top Findings 详情（仅展开 Critical / High）
+
+#### DR-01 [标题]
+
+**严重度**: Critical  
+**文档位置**: [精确的文件和章节引用]
+
+**证据**:
+- 文档分析: [来自 PRD/Architecture/ADR 的具体内容]
+- 推理链: [基于 `sequential-thinking` 的分析]
+- 类比: [其他系统中的类似已知失败，如适用]
+
+**影响**:
+- [不修复会发生什么]
+
+**建议**:
+- [最小修复方向]
+```
+
+---
+
+## 审查质量清单
+
+交付发现前，确认：
+
+- 每条发现有具体文档引用（不是笼统的"架构文档"）
+- 每条发现有明确的影响说明
+- 没有纯猜测性的发现（缺乏推理链条）
+- Critical/High 发现经过 `sequential-thinking` 验证
+- ADR 中已记录的权衡被尊重（没有在无新证据的情况下重复质疑）
+- 发现可操作（审查者能根据建议进行修复）
+

package/skills/develop-web-game/LICENSE.txt

@@ -0,0 +1,201 @@
+Apache License
+Version 2.0, January 2004
+http://www.apache.org/licenses/
+
+TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+1. Definitions.
+
+   "License" shall mean the terms and conditions for use, reproduction,
+   and distribution as defined by Sections 1 through 9 of this document.
+
+   "Licensor" shall mean the copyright owner or entity authorized by
+   the copyright owner that is granting the License.
+
+   "Legal Entity" shall mean the union of the acting entity and all
+   other entities that control, are controlled by, or are under common
+   control with that entity. For the purposes of this definition,
+   "control" means (i) the power, direct or indirect, to cause the
+   direction or management of such entity, whether by contract or
+   otherwise, or (ii) ownership of fifty percent (50%) or more of the
+   outstanding shares, or (iii) beneficial ownership of such entity.
+
+   "You" (or "Your") shall mean an individual or Legal Entity
+   exercising permissions granted by this License.
+
+   "Source" form shall mean the preferred form for making modifications,
+   including but not limited to software source code, documentation
+   source, and configuration files.
+
+   "Object" form shall mean any form resulting from mechanical
+   transformation or translation of a Source form, including but
+   not limited to compiled object code, generated documentation,
+   and conversions to other media types.
+
+   "Work" shall mean the work of authorship, whether in Source or
+   Object form, made available under the License, as indicated by a
+   copyright notice that is included in or attached to the work
+   (an example is provided in the Appendix below).
+
+   "Derivative Works" shall mean any work, whether in Source or Object
+   form, that is based on (or derived from) the Work and for which the
+   editorial revisions, annotations, elaborations, or other modifications
+   represent, as a whole, an original work of authorship. For the purposes
+   of this License, Derivative Works shall not include works that remain
+   separable from, or merely link (or bind by name) to the interfaces of,
+   the Work and Derivative Works thereof.
+
+   "Contribution" shall mean any work of authorship, including
+   the original version of the Work and any modifications or additions
+   to that Work or Derivative Works thereof, that is intentionally
+   submitted to Licensor for inclusion in the Work by the copyright owner
+   or by an individual or Legal Entity authorized to submit on behalf of
+   the copyright owner. For the purposes of this definition, "submitted"
+   means any form of electronic, verbal, or written communication sent
+   to the Licensor or its representatives, including but not limited to
+   communication on electronic mailing lists, source code control systems,
+   and issue tracking systems that are managed by, or on behalf of, the
+   Licensor for the purpose of discussing and improving the Work, but
+   excluding communication that is conspicuously marked or otherwise
+   designated in writing by the copyright owner as "Not a Contribution."
+
+   "Contributor" shall mean Licensor and any individual or Legal Entity
+   on behalf of whom a Contribution has been received by Licensor and
+   subsequently incorporated within the Work.
+
+2. Grant of Copyright License. Subject to the terms and conditions of
+   this License, each Contributor hereby grants to You a perpetual,
+   worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+   copyright license to reproduce, prepare Derivative Works of,
+   publicly display, publicly perform, sublicense, and distribute the
+   Work and such Derivative Works in Source or Object form.
+
+3. Grant of Patent License. Subject to the terms and conditions of
+   this License, each Contributor hereby grants to You a perpetual,
+   worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+   (except as stated in this section) patent license to make, have made,
+   use, offer to sell, sell, import, and otherwise transfer the Work,
+   where such license applies only to those patent claims licensable
+   by such Contributor that are necessarily infringed by their
+   Contribution(s) alone or by combination of their Contribution(s)
+   with the Work to which such Contribution(s) was submitted. If You
+   institute patent litigation against any entity (including a
+   cross-claim or counterclaim in a lawsuit) alleging that the Work
+   or a Contribution incorporated within the Work constitutes direct
+   or contributory patent infringement, then any patent licenses
+   granted to You under this License for that Work shall terminate
+   as of the date such litigation is filed.
+
+4. Redistribution. You may reproduce and distribute copies of the
+   Work or Derivative Works thereof in any medium, with or without
+   modifications, and in Source or Object form, provided that You
+   meet the following conditions:
+
+   (a) You must give any other recipients of the Work or
+       Derivative Works a copy of this License; and
+
+   (b) You must cause any modified files to carry prominent notices
+       stating that You changed the files; and
+
+   (c) You must retain, in the Source form of any Derivative Works
+       that You distribute, all copyright, patent, trademark, and
+       attribution notices from the Source form of the Work,
+       excluding those notices that do not pertain to any part of
+       the Derivative Works; and
+
+   (d) If the Work includes a "NOTICE" text file as part of its
+       distribution, then any Derivative Works that You distribute must
+       include a readable copy of the attribution notices contained
+       within such NOTICE file, excluding those notices that do not
+       pertain to any part of the Derivative Works, in at least one
+       of the following places: within a NOTICE text file distributed
+       as part of the Derivative Works; within the Source form or
+       documentation, if provided along with the Derivative Works; or,
+       within a display generated by the Derivative Works, if and
+       wherever such third-party notices normally appear. The contents
+       of the NOTICE file are for informational purposes only and
+       do not modify the License. You may add Your own attribution
+       notices within Derivative Works that You distribute, alongside
+       or as an addendum to the NOTICE text from the Work, provided
+       that such additional attribution notices cannot be construed
+       as modifying the License.
+
+   You may add Your own copyright statement to Your modifications and
+   may provide additional or different license terms and conditions
+   for use, reproduction, or distribution of Your modifications, or
+   for any such Derivative Works as a whole, provided Your use,
+   reproduction, and distribution of the Work otherwise complies with
+   the conditions stated in this License.
+
+5. Submission of Contributions. Unless You explicitly state otherwise,
+   any Contribution intentionally submitted for inclusion in the Work
+   by You to the Licensor shall be under the terms and conditions of
+   this License, without any additional terms or conditions.
+   Notwithstanding the above, nothing herein shall supersede or modify
+   the terms of any separate license agreement you may have executed
+   with Licensor regarding such Contributions.
+
+6. Trademarks. This License does not grant permission to use the trade
+   names, trademarks, service marks, or product names of the Licensor,
+   except as required for reasonable and customary use in describing the
+   origin of the Work and reproducing the content of the NOTICE file.
+
+7. Disclaimer of Warranty. Unless required by applicable law or
+   agreed to in writing, Licensor provides the Work (and each
+   Contributor provides its Contributions) on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+   implied, including, without limitation, any warranties or conditions
+   of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+   PARTICULAR PURPOSE. You are solely responsible for determining the
+   appropriateness of using or redistributing the Work and assume any
+   risks associated with Your exercise of permissions under this License.
+
+8. Limitation of Liability. In no event and under no legal theory,
+   whether in tort (including negligence), contract, or otherwise,
+   unless required by applicable law (such as deliberate and grossly
+   negligent acts) or agreed to in writing, shall any Contributor be
+   liable to You for damages, including any direct, indirect, special,
+   incidental, or consequential damages of any character arising as a
+   result of this License or out of the use or inability to use the
+   Work (including but not limited to damages for loss of goodwill,
+   work stoppage, computer failure or malfunction, or any and all
+   other commercial damages or losses), even if such Contributor
+   has been advised of the possibility of such damages.
+
+9. Accepting Warranty or Additional Liability. While redistributing
+   the Work or Derivative Works thereof, You may choose to offer,
+   and charge a fee for, acceptance of support, warranty, indemnity,
+   or other liability obligations and/or rights consistent with this
+   License. However, in accepting such obligations, You may act only
+   on Your own behalf and on Your sole responsibility, not on behalf of
+   any other Contributor, and only if You agree to indemnify,
+   defend, and hold each Contributor harmless for any liability
+   incurred by, or claims asserted against, such Contributor by reason
+   of your accepting any such warranty or additional liability.
+
+END OF TERMS AND CONDITIONS
+
+APPENDIX: How to apply the Apache License to your work.
+
+   To apply the Apache License to your work, attach the following
+   boilerplate notice, with the fields enclosed by brackets "[]"
+   replaced with your own identifying information. (Don\'t include
+   the brackets!)  The text should be enclosed in the appropriate
+   comment syntax for the file format. We also recommend that a
+   file or class name and description of purpose be included on the
+   same "printed page" as the copyright notice for easier
+   identification within third-party archives.
+
+Copyright [yyyy] [name of copyright owner]
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+    http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.