@pasko70/pibo 1.0.5 → 1.2.0

package/skills/builtin/ralph-loop/SKILL.md

@@ -0,0 +1,359 @@
+---
+name: ralph-loop
+description: Plan, create, run, monitor, and review Ralph implementation loops with reusable Docker workers, git worktrees, PRD batches, stop policies, maxIterations, progress files, commits, and safe agent instructions. Use whenever the user wants to start a Ralph job, run an implementation loop, prepare autonomous PRD execution, monitor Ralph, debug Ralph job behavior, or capture the standard Ralph loop workflow.
+---
+
+# Ralph Loop Workflow
+
+Use this skill to create and operate a Ralph implementation loop safely. Ralph runs repeated Pibo agent sessions against an objective, usually from PRD stories. The core pattern is:
+
+1. Prepare a clean git worktree.
+2. Reuse a dedicated Docker dev worker for runtime, builds, tests, gateway, and browser checks.
+3. Create a Ralph job from a built-in template.
+4. Give Ralph explicit operating instructions.
+5. Start only after inspection.
+6. Monitor with Ralph, debug session, events, trace, and git status.
+7. Require progress updates and commits after completed stories or coherent story groups.
+
+For CLI details, first discover the current implementation:
+
+```bash
+pibo tools guide ralph ralph
+pibo ralph templates --json
+pibo ralph conditions
+```
+
+Do not duplicate the whole CLI guide in answers. Use it as the live source of truth.
+
+## When to Use Which Skill
+
+- Use `ralph-loop` for job setup, Docker/worktree strategy, monitoring, stop conditions, and loop operations.
+- Use `ralph-prd-json` to convert Markdown PRDs/specs into Ralph `prd.json` story files.
+- Use `pibo-docker-system` when a Docker worker must be created, inspected, authenticated, or debugged.
+- Use `github-server-flow` when pushing branches or opening upstream PRs.
+
+## Default Safety Rules
+
+Apply these unless the user says otherwise:
+
+- Reuse an existing Docker dev worker. Do not create or release workers without explicit approval.
+- Keep source edits and git commits in the host worktree.
+- Use the Docker worker only for runtime, builds, tests, dev gateway restarts, and browser/web verification.
+- Do not restart or modify host services such as `pibo-web.service` from the Ralph job.
+- Do not expose tokens or credentials in prompts, logs, commits, or reports.
+- Keep a progress file at the repo root, usually `IMPLEMENTATION_PROGRESS.md`.
+- Commit after each completed story or coherent story group.
+- Prefer starting the job stopped, inspect it, then start it.
+- Stop normally with `pibo ralph stop`; use `cancel` only when stuck or unsafe.
+
+## Standard Topology
+
+Use a dedicated branch and worktree per Ralph loop:
+
+```bash
+cd /root/code/pibo
+git fetch upstream main
+git switch main
+git merge --ff-only upstream/main
+
+git worktree add .worktrees/<loop-name> -b <branch-name>
+cd .worktrees/<loop-name>
+```
+
+Typical names:
+
+- Worktree: `/root/code/pibo/.worktrees/<feature-or-loop-name>`
+- Branch: `<feature-or-loop-name>`
+- Docker worker: `pibo-dev-<feature-or-loop-name>`
+- Progress file: `<worktree>/IMPLEMENTATION_PROGRESS.md`
+
+If a Docker worker already exists, reuse it. A typical container command is:
+
+```bash
+docker exec <worker-name> bash -lc 'cd /workspace && <command>'
+```
+
+The container usually sees the worktree at `/workspace`. Git metadata may not work inside the container, so keep git operations on the host worktree.
+
+## Progress File Template
+
+Create or update `IMPLEMENTATION_PROGRESS.md` in the worktree root:
+
+```markdown
+# <Feature> Implementation Progress
+
+## Ralph job setup
+
+- Created: <date>
+- Target scope: app-global
+- Target room: `<room-id>`
+- Profile: `pibo-agent`
+- Template: `<template-id>`
+- Worktree: `<absolute-host-worktree>`
+- Branch: `<branch>`
+- Docker dev worker: `<worker-name>`
+- Docker web port: `<port>`
+- Docker gateway port: `<port>`
+- Docker CDP port: `<port>`
+
+## Scope
+
+Implement:
+
+`<paths to PRDs/specs/tasks>`
+
+## Operating notes
+
+- Keep implementation work in the dedicated host worktree above.
+- Reuse the existing Docker dev worker for runtime, tests, builds, and gateway restarts.
+- Do not create or release Docker workers unless explicitly asked.
+- Do not restart or modify host services.
+- Run container commands as `docker exec <worker> bash -lc 'cd /workspace && <command>'`.
+- Git operations and commits must be done on the host worktree path.
+- Batch user stories sensibly. Stop the session when a coherent batch is complete.
+- Commit after each completed story or coherent story group.
+- Before starting new work, review recent commits in this worktree/branch.
+
+## Progress log
+
+- <date>: Created worktree and validated Docker worker.
+```
+
+## Ralph Job Creation Flow
+
+Prefer this sequence:
+
+1. Prepare or verify worktree, Docker worker, and progress file.
+2. Inspect templates.
+3. Create the job stopped.
+4. Inspect the job JSON.
+5. Start after confirmation.
+
+Example:
+
+```bash
+ROOM_ID='<room-id>'
+
+pibo ralph templates --json
+
+pibo ralph add \
+  --room "$ROOM_ID" \
+  --profile pibo-agent \
+  --template prd-batch-stories \
+  --name "Implement <feature> PRD batch" \
+  --prompt "$(cat /tmp/ralph-loop-prompt.txt)" \
+  --json
+
+pibo ralph list --all --json
+pibo ralph start <job-id>
+```
+
+Use `--start` only when the user explicitly wants immediate launch or the job has already been reviewed.
+
+## Template Choice
+
+Use the built-in templates as source-of-truth presets:
+
+- `prd-single-story-standard`: one failing PRD story per run, useful for risky changes.
+- `prd-batch-stories`: multiple PRD stories in priority order, useful for a prepared batch with clear commits.
+- `single-run-objective`: one focused non-PRD task, stops after one completed run attempt.
+
+Explicit CLI options override template fields. Keep loaded fields editable when preparing jobs.
+
+## Stop Conditions and maxIterations
+
+Ralph has two layers of stopping:
+
+- Semantic stop conditions, e.g. promise-complete or story completion.
+- `maxIterations` fallback.
+
+`maxIterations` should be treated as a hard fallback over **completed run attempts**, including:
+
+- `ok`
+- `error`
+- `cancelled`
+
+This prevents endless loops when runs repeatedly fail or get cancelled before satisfying a semantic stop condition.
+
+Use a high but bounded value for large PRD batches, such as `100`, and a small value for focused one-shot tasks, such as `1`. For PRD/story batches, a good rule of thumb is `maxIterations = 3 × total user stories`; adjust freely when the job is not PRD-based, the stop condition is different, or the risk profile calls for a smaller or larger fallback.
+
+### Promise-complete Token Safety
+
+Ralph's promise-complete condition is a literal marker check on the final answer. Older deployments and some jobs may treat any mention as a match; even with stricter own-line matching, quoted examples are dangerous. If an agent writes the literal completion marker in a negative sentence, quote, explanation, or example, the loop can stop accidentally.
+
+When preparing prompts for jobs with a promise-complete condition:
+
+- Do not include the full literal completion marker contiguously in the prompt.
+- Describe it as the XML completion marker, or as the opening tag `<promise>`, the word `COMPLETE`, and the closing tag `</promise>`.
+- Instruct the agent not to quote, negate, explain, or mention the literal marker unless all completion criteria are satisfied and it intentionally wants to stop the job.
+- For incomplete work, instruct the agent to say "completion marker omitted" instead of writing the literal marker in any form.
+- When reviewing a stopped job with reason `promise-complete`, inspect the final answer for accidental mentions such as "not complete" statements before assuming the work is finished.
+
+## Prompt Instructions Ralph Needs
+
+The job prompt is the most important part. It should be explicit about environment, scope, verification, commits, and forbidden actions.
+
+Include:
+
+- Exact host worktree path.
+- Exact branch name.
+- Exact Docker worker name and ports.
+- Exact PRD/spec paths to implement.
+- Progress file path.
+- Commit policy.
+- Test/build policy.
+- Real-path validation policy for user-facing work.
+- Safety restrictions.
+- What to do first.
+- When to stop the current session.
+
+### Prompt Skeleton
+
+```text
+Implement <feature/scope> using the dedicated Ralph loop environment.
+
+Environment:
+- Host worktree: <absolute-host-worktree>
+- Branch: <branch>
+- Docker dev worker: <worker-name>
+- Container workspace: /workspace
+- Web: http://127.0.0.1:<web-port>/apps/chat
+- Gateway: <gateway-port>
+- CDP: <cdp-port>
+- Progress file: <absolute-host-worktree>/IMPLEMENTATION_PROGRESS.md
+
+Scope:
+- Implement PRDs under: <path/glob>
+- Total workload: <optional story count>
+
+Operating rules:
+- Work in the host worktree. Use absolute paths or cd into the worktree before edits.
+- Use the Docker worker for runtime, tests, builds, dev gateway restarts, and browser checks.
+- Run container commands as: docker exec <worker> bash -lc 'cd /workspace && <command>'.
+- Do not create or release Docker workers.
+- Do not restart or modify host pibo-web.service.
+- Do not expose credentials.
+- Keep telemetry/privacy/product constraints from the PRDs.
+- If using promise-complete, never quote, negate, explain, or mention the literal completion marker unless all completion criteria are satisfied; for incomplete work, say "completion marker omitted".
+- Update IMPLEMENTATION_PROGRESS.md with decisions, completed stories, validation, commits, blockers, and next steps.
+- For each completed story, record concrete evidence: commands run, fake/demo/real path, browser/PTY/manual checks, and observed result.
+- Commit after every completed story or coherent story group.
+
+First actions:
+1. cd <host-worktree>.
+2. Run git status and recent git log.
+3. Read IMPLEMENTATION_PROGRESS.md.
+4. Read the PRD JSON files and related specs/tasks/decisions.
+5. Select a coherent next story group.
+6. State the selected group in the progress file.
+
+Completion rules for each story group:
+- Implement the smallest coherent slice.
+- Run focused tests first.
+- Run typecheck/build when appropriate.
+- For user-facing CLI, TUI, Web UI, gateway, runtime, auth, persistence, or agent-routing behavior, exercise the closest practical default path when feasible. Fake/demo/mocked checks are useful but should not be the only evidence for default-path behavior.
+- Commit from the host worktree with a clear message.
+- Update progress with validation, evidence tier, observed result, and commit hash.
+- Stop the session if the coherent batch is complete or if blocked.
+```
+
+## Validation Evidence Audit
+
+Use this audit lightly, not as a rigid ceremony. It exists to catch false confidence before a Ralph job marks user-facing work complete.
+
+Before the final story group is marked complete, or before emitting a completion marker, have Ralph list the top user-facing happy paths and the evidence for each. Classify each check as one of:
+
+- unit/fixture
+- fake/demo
+- integration-lite
+- real default path
+- browser/PTY/manual verified
+- not verified, with reason
+
+For user-facing CLI, TUI, Web UI, gateway, runtime, auth, persistence, or agent-routing features, demo/fake-only validation should trigger a pause or explicit risk note if the real default path is locally testable. Do not require heavyweight E2E tests for every helper or internal refactor; scale the audit to the risk and scope.
+
+## Monitoring Checklist
+
+Use read-only checks unless the user asks for intervention:
+
+```bash
+pibo ralph list --all --json
+pibo ralph runs --job <job-id> --json
+pibo debug session <pibo-session-id>
+pibo debug events <pibo-session-id> --limit 30
+pibo debug trace <pibo-session-id> --running-only --check
+```
+
+Also inspect git state:
+
+```bash
+cd <worktree>
+git status --short --branch
+git log --oneline --decorate -n 8
+tail -80 IMPLEMENTATION_PROGRESS.md
+```
+
+Interpretation tips:
+
+- A running session with fresh events is healthy even if a trace wrapper reports `status: error`; compare session status, events, and Ralph run status before acting.
+- If the worktree has uncommitted changes for a long time, check whether Ralph is still actively editing/testing.
+- If a completed story is uncommitted, remind or intervene only with user approval unless the job instructions authorize commits.
+
+## Review and Intervention Strategy
+
+Early review should be read-only:
+
+1. Confirm job enabled/running state.
+2. Confirm current run and session IDs.
+3. Confirm session events are fresh.
+4. Confirm worktree branch and changed files.
+5. Confirm progress file is being updated.
+6. Confirm Docker worker is reachable if runtime checks are expected.
+7. Report concise status, risks, and whether to continue.
+
+Intervene only when:
+
+- The job is unsafe.
+- It touches forbidden host services.
+- It uses the wrong repo/worktree/branch.
+- It creates/release workers without approval.
+- It is stale and not making progress.
+- It repeatedly fails and `maxIterations` is being consumed.
+
+Prefer `pibo ralph stop` for graceful shutdown. Use `pibo ralph cancel` only for stuck or unsafe active runs.
+
+## Sync and PR Strategy
+
+For host repo sync:
+
+```bash
+cd /root/code/pibo
+git fetch upstream main
+git switch main
+git merge --ff-only upstream/main
+git switch developer
+git merge --ff-only main
+git push origin main developer
+```
+
+For Ralph worktree branches:
+
+- Do not merge or rebase a running Ralph worktree without checking active edits.
+- Let Ralph finish and commit a coherent batch first.
+- Then sync intentionally, resolve conflicts, run tests, and push.
+- Open upstream PRs with the project helper when ready.
+
+## Minimal User Report
+
+Keep reports short:
+
+```text
+Ralph läuft gesund.
+- Job: <id>
+- Run: <id>, Status: running
+- Session: <id>, letzte Events frisch
+- Worktree: <branch>, aktuelle Änderungen: <files>
+- Progress: <last completed story/commit>
+- Risiko: <none/short note>
+Empfehlung: weiterlaufen lassen / stoppen / eingreifen.
+```

package/skills/builtin/ralph-prd-json/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: ralph-prd-json
+description: Convert Markdown PRDs and feature specs into Ralph prd.json story batches. Use whenever the user asks to convert a PRD for Ralph, create Ralph JSON, split a PRD into executable stories, prepare PRD story files, or mentions prd.json for autonomous implementation.
+---
+
+# Ralph PRD JSON Converter
+
+Convert existing PRDs, specs, or Markdown feature descriptions into the `prd.json` format Ralph can execute.
+
+Use this skill for **PRD/story shaping**, not for creating or operating the Ralph job itself. For job creation, Docker worker reuse, worktrees, stop policies, and monitoring, use the `ralph-loop` skill.
+
+## Output Format
+
+```json
+{
+  "project": "[Project Name]",
+  "branchName": "ralph/[feature-name-kebab-case]",
+  "description": "[Feature description from PRD title/intro]",
+  "userStories": [
+    {
+      "id": "US-001",
+      "title": "[Story title]",
+      "description": "As a [user], I want [feature] so that [benefit]",
+      "acceptanceCriteria": [
+        "Criterion 1",
+        "Criterion 2",
+        "Typecheck passes"
+      ],
+      "priority": 1,
+      "passes": false,
+      "notes": ""
+    }
+  ]
+}
+```
+
+## Story Size Rule
+
+Each story should fit in one Ralph iteration and one context window. Split broad requirements until each story has a focused implementation and verification path.
+
+Good story sizes:
+
+- Add a database column and migration.
+- Add one CLI subcommand and tests.
+- Add one service method plus focused tests.
+- Add one UI component to an existing page.
+
+Too large:
+
+- Build the whole dashboard.
+- Add the entire telemetry system.
+- Refactor the API.
+
+Rule of thumb: if the change cannot be described in 2 to 3 sentences, split it.
+
+## Story Ordering
+
+Order by dependencies:
+
+1. Schema and migrations.
+2. Store/service layer.
+3. Runtime instrumentation or backend logic.
+4. CLI/API/UI surfaces.
+5. Docs and validation.
+
+Earlier stories must not depend on later stories.
+
+## Acceptance Criteria
+
+Use criteria Ralph can verify.
+
+Good:
+
+- `Add telemetry_turns table with session, turn, status, timestamps, and retention fields`.
+- `pibo debug telemetry stats --json returns counts by retention class`.
+- `Focused tests pass`.
+- `Typecheck passes`.
+
+Bad:
+
+- `Works correctly`.
+- `Good UX`.
+- `Handles everything`.
+
+Always include `Typecheck passes`. Add `Tests pass` for logic. Add browser verification when a browser UI is affected, and PTY or interactive verification when a CLI/TUI flow is affected.
+
+### Real-path criteria for user-facing work
+
+For CLI, TUI, Web UI, gateway, auth, runtime, persistence, or agent-routing stories, include an acceptance criterion for the closest practical default user path. Keep it proportional: a small component may only need a render test, while a messaging or navigation feature should exercise the real command, route, API, or runtime path when feasible.
+
+Fake sources, demo mode, mocks, and snapshots are good supporting evidence, but avoid making them the only evidence for behavior users will exercise directly. If the real path cannot be tested in the story, add an explicit criterion or note explaining why and what later story will cover it.
+
+Name the observable result, not just the mechanism. Prefer criteria like:
+
+- `Running pibo tui:sessions without --demo can create/select a session, send a message through the real router, and show an assistant reply`.
+- `The agent picker lists custom agents from the canonical custom-agent store, including an existing pibo-agent fixture or documented local equivalent`.
+- `Opening /sessions/<id> in the worker Web UI shows the session created by the CLI flow`.
+
+### Evidence notes
+
+When a story is marked `passes: true`, notes should record the concrete evidence: commands run, whether the path was fake/demo/real, browser or PTY checks performed, and any manual observation. `Tests pass` alone is not enough for user-facing integration stories.
+
+## Conversion Rules
+
+1. One user story per JSON entry.
+2. IDs are sequential, e.g. `US-001`.
+3. Priority follows dependency order, then document order.
+4. New stories start with `passes: false` and empty `notes`.
+5. `branchName` is kebab-case and prefixed with `ralph/`.
+6. Keep stories independent enough that Ralph can commit after each story or coherent group.
+
+## Checklist Before Saving
+
+- [ ] Stories fit one iteration.
+- [ ] Stories are ordered by dependency.
+- [ ] Acceptance criteria are verifiable.
+- [ ] Every story has `Typecheck passes`.
+- [ ] Logic stories include `Tests pass`.
+- [ ] UI stories include browser verification when a browser surface is affected.
+- [ ] CLI/TUI stories include PTY or interactive validation when the interactive path is in scope and feasible.
+- [ ] User-facing integration stories include a real/default-path check or an explicit reason it is deferred.
+- [ ] Fake/demo/mocked checks are not the only evidence for default-path behavior unless documented as a deliberate limitation.
+- [ ] No story depends on a later story.

package/skills/builtin/skill-creator/LICENSE.txt

@@ -0,0 +1,202 @@
+
+                                 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 2026 Anthropic, PBC.
+
+   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.