ctxora 6.2.2 → 6.4.0

package/src/harness_context/skills/ecc/google-workspace-ops/LICENSE.ecc

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Affaan Mustafa
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/src/harness_context/skills/ecc/google-workspace-ops/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: google-workspace-ops
+description: Operate across Google Drive, Docs, Sheets, and Slides as one workflow surface for plans, trackers, decks, and shared documents. Use when the user needs to find, summarize, edit, migrate, or clean up Google Workspace assets without dropping to raw tool calls.
+metadata:
+  origin: ECC
+---
+
+# Google Workspace Ops
+
+This skill is for operating shared docs, spreadsheets, and decks as working systems, not just editing one file in isolation.
+
+## When to Use
+
+- User needs to find a doc, sheet, or deck and update it in place
+- Consolidating plans, trackers, notes, or customer lists stored in Google Drive
+- Cleaning or restructuring a shared spreadsheet
+- Importing, repairing, or reformatting a Google Slides deck
+- Producing summaries from Docs, Sheets, or Slides for decision-making
+
+## Preferred Tool Surface
+
+Use Google Drive as the entry point, then switch to the right specialist:
+
+- Google Docs for text-heavy docs
+- Google Sheets for tabular work, formulas, and charts
+- Google Slides for decks, imports, template migration, and cleanup
+
+Do not guess structure from filenames alone. Inspect first.
+
+## Workflow
+
+### 1. Find the asset
+
+Start with the Drive search surface to locate:
+
+- the exact file
+- sibling assets
+- likely duplicates
+- recently modified versions
+
+If several documents look similar, confirm by title, owner, modified time, or folder.
+
+### 2. Inspect before editing
+
+Before making changes:
+
+- summarize current structure
+- identify tabs, headings, or slide count
+- detect whether the task is local cleanup or structural surgery
+
+Pick the smallest tool that can safely perform the work.
+
+### 3. Edit with precision
+
+- For Docs: use index-aware edits, not vague rewrites
+- For Sheets: operate on explicit tabs and ranges
+- For Slides: distinguish content edits from visual cleanup or template migration
+
+If the requested work is visual or layout-sensitive, iterate with inspection and verification instead of one giant blind update.
+
+### 4. Keep the working system clean
+
+When the file is part of a larger workflow, also surface:
+
+- duplicate trackers
+- outdated decks
+- stale docs vs canonical docs
+- whether the asset should be archived, merged, or renamed
+
+## Output Format
+
+Use:
+
+```text
+ASSET
+- file name
+- type
+- why this is the right file
+
+CURRENT STATE
+- structure summary
+- key problems or blockers
+
+ACTION
+- edits made or recommended
+
+FOLLOW-UPS
+- archive / merge / duplicate cleanup / next file to update
+```
+
+## Good Use Cases
+
+- "Find the active planning doc and condense it"
+- "Clean up this customer spreadsheet and show me the churn-risk rows"
+- "Import this deck into Slides and make it presentable"
+- "Find the current tracker, not the stale duplicate"

package/src/harness_context/skills/ecc/growth-log/LICENSE.ecc

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Affaan Mustafa
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/src/harness_context/skills/ecc/growth-log/SKILL.md

@@ -0,0 +1,128 @@
+---
+name: growth-log
+description: "Use after a complex task, failure, or when reviewing what was learned. Teaches how to write growth logs that extract reusable patterns — not diary entries."
+metadata:
+  version: 1.1.0
+  origin: ECC
+---
+
+# Growth Log Skill
+
+> **The problem:** Most people write "fixed a bug in X" as a learning log. That's a diary entry, not a learning artifact. A real growth log extracts the *pattern* so you recognize it next time.
+>
+> **This skill teaches:** How to write learning entries that compound across sessions. Works with any note-taking system — Markdown files, Notion, Obsidian, plain text. Templates are generic; adapt to your setup.
+
+## When to Activate
+
+- After completing a complex task (multi-file, new feature, architecture change)
+- After a failure, mistake, or "that was harder than expected" moment
+- When you want to review what you've learned over a period
+
+**When NOT to activate:** Trivial changes (typo fixes, single-line tweaks, config value changes with no debugging). The threshold: *did this task involve debugging, redoing, rollback, or a non-obvious decision?* If yes → write an entry. If no → skip.
+
+## The Three Rules
+
+### Rule 1: Failures > Achievements
+
+A failure is nutritionally denser than a success. One bug that took 2 hours to find teaches more than 3 features that worked first try.
+
+**Bad:** "Successfully implemented the login flow."
+**Good (web dev):** "Login flow: session token wasn't persisting because the cookie `SameSite` defaulted to `Lax` in Chrome 128+. Pattern: always explicitly set `SameSite=None; Secure` when cross-origin. Signal to recognize: auth breaks after browser upgrade or when crossing origin boundaries."
+**Good (data pipeline):** "CSV import failed silently on empty rows because `pandas.read_csv(dropna=False)` keeps zero-width rows that `len()` counts as valid. Pattern: always `df.dropna(how='all', inplace=True)` before row-count validation."
+
+### Rule 2: The Bole Principle (伯乐原则)
+
+Before writing a new entry, ask: *"Is this fundamentally the same as something I already recorded?"*
+
+Same root cause, different symptom → **merge**, don't duplicate. New root cause → new entry.
+
+**How to check:** Search existing entries for keywords from your root cause before writing. If you find a match, add your new symptom as an additional example under the existing entry rather than creating a duplicate.
+
+**Example:** "Forgot to update the output index after creating a file" and "Forgot to update skill ratings after a task" — same root cause (no automatic capture trigger). Merge into one entry about "post-task capture gaps."
+
+### Rule 3: Must Be Transferable
+
+Every entry must answer: *"Next time I face a similar situation, what do I do differently?"*
+
+If you can't write that sentence, you haven't extracted the pattern yet.
+
+**How to extract a pattern from a concrete event:**
+1. State what happened in one sentence
+2. Ask "why?" iteratively until you reach root cause (usually 3-5 whys)
+3. Generalize: "What class of problem is this?" (not "Chrome 128 bug" but "browser default change breaking existing behavior")
+4. Formulate as: "Next time I see [signal], I will [action]."
+5. Name the signal: what specific observable tells you this pattern is active?
+
+## Entry Template
+
+**Scope:** One entry per distinct root cause. Typical length: 4-8 sentences. If it takes >2 minutes to write, you're narrating events. If <30 seconds, you haven't gone deep enough.
+
+```markdown
+## [Title: the pattern, not the event]
+
+### Context
+- What was I trying to do?
+- What went wrong / what worked surprisingly well?
+
+### Root Cause / Core Insight
+- The underlying mechanism, not just the symptom
+
+### The Pattern (transferable)
+- Next time [similar situation], I will [specific action].
+- Signal to recognize: [what observable tells me this pattern is active?]
+
+### Related
+- [entry-name](../path/to/related-entry.md)
+```
+
+## Entry Types
+
+All four types use the template above. The type determines which sections carry the most weight:
+
+| Type | When to Use | Emphasis | Example Title |
+|------|------------|----------|---------------|
+| **Failure** | Something broke, needed debugging, or required rework | Root Cause | "Config inheritance ≠ behavior inheritance across sessions" |
+| **Methodology** | A repeatable process emerged from the work | Context / Pattern | "PPT → open-book exam study guide: three-layer structure" |
+| **Pattern Discovery** | A reusable insight about tools, systems, or thinking | Pattern section | "PR description template: describe the gap, not the feature" |
+| **Capability Change** | A measurable skill improvement | Context (before vs after) | "Git: from clone/push to independent PR with 12 commits" |
+
+## Quality Checklist
+
+Before finalizing a growth log entry:
+
+- [ ] Does the title name the *pattern*, not the event?
+- [ ] Is there a "Next time I will..." sentence?
+- [ ] Is the "Signal to recognize" specific enough to trigger the pattern next time?
+- [ ] Did I search existing entries for duplicates before writing? (Bole Principle)
+- [ ] Is the root cause distinguished from the symptom?
+- [ ] Are related memories cross-linked?
+- [ ] Is the entry 4-8 sentences? Shorter = too shallow; longer = narrating events.
+
+## Anti-Patterns
+
+- Avoid: "Fixed bug in payment module" (event, not pattern)
+- Avoid: Copying the git commit message verbatim (commits describe what changed; logs extract why it matters)
+- Avoid: Writing an entry for every commit (only when a pattern emerges)
+- Avoid: Skipping the transferable sentence (without it, it's just a diary — this is non-negotiable)
+- Avoid: Duplicating the same pattern under different titles (violates Bole Principle — search before writing)
+
+## Storage
+
+Store entries wherever you keep notes. Common patterns:
+- Markdown files in a `growth-log/` directory (one file per day: `YYYY-MM-DD.md`)
+- A dedicated section in Notion, Obsidian, or your note-taking app
+- Plain text files with a consistent naming convention
+
+Pick one convention and stick to it. Searchability matters more than format.
+
+## If You Use Delivery Gate
+
+The `delivery-gate` Stop hook checks that learning files were modified today via filesystem timestamps. This skill teaches *what to write* — so the file that delivery-gate checks actually contains useful patterns, not empty timestamps.
+
+```
+Task completes → delivery-gate checks: was the learning file touched today?
+  → Stale (no file modified): block — "what did you learn?"
+  → Fresh (file touched): pass — this skill ensures the content is useful
+```
+
+Having enforcement without methodology → empty entries. Having methodology without enforcement → forgotten captures. Each is independently useful; together they close the loop.

package/src/harness_context/skills/ecc/healthcare-cdss-patterns/LICENSE.ecc

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Affaan Mustafa
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/src/harness_context/skills/ecc/healthcare-cdss-patterns/SKILL.md

@@ -0,0 +1,246 @@
+---
+name: healthcare-cdss-patterns
+description: Clinical Decision Support System (CDSS) development patterns. Drug interaction checking, dose validation, clinical scoring (NEWS2, qSOFA), alert severity classification, and integration into EMR workflows. Use when building clinical decision support — drug interaction checks, dose validation, clinical scoring, or alert severity.
+metadata:
+  version: "1.0.0"
+  origin: Health1 Super Speciality Hospitals — contributed by Dr. Keyur Patel
+---
+
+# Healthcare CDSS Development Patterns
+
+Patterns for building Clinical Decision Support Systems that integrate into EMR workflows. CDSS modules are patient safety critical — zero tolerance for false negatives.
+
+## When to Use
+
+- Implementing drug interaction checking
+- Building dose validation engines
+- Implementing clinical scoring systems (NEWS2, qSOFA, APACHE, GCS)
+- Designing alert systems for abnormal clinical values
+- Building medication order entry with safety checks
+- Integrating lab result interpretation with clinical context
+
+## How It Works
+
+The CDSS engine is a **pure function library with zero side effects**. Input clinical data, output alerts. This makes it fully testable.
+
+Three primary modules:
+
+1. **`checkInteractions(newDrug, currentMeds, allergies)`** — Checks a new drug against current medications and known allergies. Returns severity-sorted `InteractionAlert[]`. Uses `DrugInteractionPair` data model.
+2. **`validateDose(drug, dose, route, weight, age, renalFunction)`** — Validates a prescribed dose against weight-based, age-adjusted, and renal-adjusted rules. Returns `DoseValidationResult`.
+3. **`calculateNEWS2(vitals)`** — National Early Warning Score 2 from `NEWS2Input`. Returns `NEWS2Result` with total score, risk level, and escalation guidance.
+
+```
+EMR UI
+  ↓ (user enters data)
+CDSS Engine (pure functions, no side effects)
+  ├── Drug Interaction Checker
+  ├── Dose Validator
+  ├── Clinical Scoring (NEWS2, qSOFA, etc.)
+  └── Alert Classifier
+  ↓ (returns alerts)
+EMR UI (displays alerts inline, blocks if critical)
+```
+
+### Drug Interaction Checking
+
+```typescript
+interface DrugInteractionPair {
+  drugA: string;           // generic name
+  drugB: string;           // generic name
+  severity: 'critical' | 'major' | 'minor';
+  mechanism: string;
+  clinicalEffect: string;
+  recommendation: string;
+}
+
+function checkInteractions(
+  newDrug: string,
+  currentMedications: string[],
+  allergyList: string[]
+): InteractionAlert[] {
+  if (!newDrug) return [];
+  const alerts: InteractionAlert[] = [];
+  for (const current of currentMedications) {
+    const interaction = findInteraction(newDrug, current);
+    if (interaction) {
+      alerts.push({ severity: interaction.severity, pair: [newDrug, current],
+        message: interaction.clinicalEffect, recommendation: interaction.recommendation });
+    }
+  }
+  for (const allergy of allergyList) {
+    if (isCrossReactive(newDrug, allergy)) {
+      alerts.push({ severity: 'critical', pair: [newDrug, allergy],
+        message: `Cross-reactivity with documented allergy: ${allergy}`,
+        recommendation: 'Do not prescribe without allergy consultation' });
+    }
+  }
+  return alerts.sort((a, b) => severityOrder(a.severity) - severityOrder(b.severity));
+}
+```
+
+Interaction pairs must be **bidirectional**: if Drug A interacts with Drug B, then Drug B interacts with Drug A.
+
+### Dose Validation
+
+```typescript
+interface DoseValidationResult {
+  valid: boolean;
+  message: string;
+  suggestedRange: { min: number; max: number; unit: string } | null;
+  factors: string[];
+}
+
+function validateDose(
+  drug: string,
+  dose: number,
+  route: 'oral' | 'iv' | 'im' | 'sc' | 'topical',
+  patientWeight?: number,
+  patientAge?: number,
+  renalFunction?: number
+): DoseValidationResult {
+  const rules = getDoseRules(drug, route);
+  if (!rules) return { valid: true, message: 'No validation rules available', suggestedRange: null, factors: [] };
+  const factors: string[] = [];
+
+  // SAFETY: if rules require weight but weight missing, BLOCK (not pass)
+  if (rules.weightBased) {
+    if (!patientWeight || patientWeight <= 0) {
+      return { valid: false, message: `Weight required for ${drug} (mg/kg drug)`,
+        suggestedRange: null, factors: ['weight_missing'] };
+    }
+    factors.push('weight');
+    const maxDose = rules.maxPerKg * patientWeight;
+    if (dose > maxDose) {
+      return { valid: false, message: `Dose exceeds max for ${patientWeight}kg`,
+        suggestedRange: { min: rules.minPerKg * patientWeight, max: maxDose, unit: rules.unit }, factors };
+    }
+  }
+
+  // Age-based adjustment (when rules define age brackets and age is provided)
+  if (rules.ageAdjusted && patientAge !== undefined) {
+    factors.push('age');
+    const ageMax = rules.getAgeAdjustedMax(patientAge);
+    if (dose > ageMax) {
+      return { valid: false, message: `Exceeds age-adjusted max for ${patientAge}yr`,
+        suggestedRange: { min: rules.typicalMin, max: ageMax, unit: rules.unit }, factors };
+    }
+  }
+
+  // Renal adjustment (when rules define eGFR brackets and eGFR is provided)
+  if (rules.renalAdjusted && renalFunction !== undefined) {
+    factors.push('renal');
+    const renalMax = rules.getRenalAdjustedMax(renalFunction);
+    if (dose > renalMax) {
+      return { valid: false, message: `Exceeds renal-adjusted max for eGFR ${renalFunction}`,
+        suggestedRange: { min: rules.typicalMin, max: renalMax, unit: rules.unit }, factors };
+    }
+  }
+
+  // Absolute max
+  if (dose > rules.absoluteMax) {
+    return { valid: false, message: `Exceeds absolute max ${rules.absoluteMax}${rules.unit}`,
+      suggestedRange: { min: rules.typicalMin, max: rules.absoluteMax, unit: rules.unit },
+      factors: [...factors, 'absolute_max'] };
+  }
+  return { valid: true, message: 'Within range',
+    suggestedRange: { min: rules.typicalMin, max: rules.typicalMax, unit: rules.unit }, factors };
+}
+```
+
+### Clinical Scoring: NEWS2
+
+```typescript
+interface NEWS2Input {
+  respiratoryRate: number; oxygenSaturation: number; supplementalOxygen: boolean;
+  temperature: number; systolicBP: number; heartRate: number;
+  consciousness: 'alert' | 'voice' | 'pain' | 'unresponsive';
+}
+interface NEWS2Result {
+  total: number;           // 0-20
+  risk: 'low' | 'low-medium' | 'medium' | 'high';
+  components: Record<string, number>;
+  escalation: string;
+}
+```
+
+Scoring tables must match the Royal College of Physicians specification exactly.
+
+### Alert Severity and UI Behavior
+
+| Severity | UI Behavior | Clinician Action Required |
+|----------|-------------|--------------------------|
+| Critical | Block action. Non-dismissable modal. Red. | Must document override reason to proceed |
+| Major | Warning banner inline. Orange. | Must acknowledge before proceeding |
+| Minor | Info note inline. Yellow. | Awareness only, no action required |
+
+Critical alerts must NEVER be auto-dismissed or implemented as toast notifications. Override reasons must be stored in the audit trail.
+
+### Testing CDSS (Zero Tolerance for False Negatives)
+
+```typescript
+describe('CDSS — Patient Safety', () => {
+  INTERACTION_PAIRS.forEach(({ drugA, drugB, severity }) => {
+    it(`detects ${drugA} + ${drugB} (${severity})`, () => {
+      const alerts = checkInteractions(drugA, [drugB], []);
+      expect(alerts.length).toBeGreaterThan(0);
+      expect(alerts[0].severity).toBe(severity);
+    });
+    it(`detects ${drugB} + ${drugA} (reverse)`, () => {
+      const alerts = checkInteractions(drugB, [drugA], []);
+      expect(alerts.length).toBeGreaterThan(0);
+    });
+  });
+  it('blocks mg/kg drug when weight is missing', () => {
+    const result = validateDose('gentamicin', 300, 'iv');
+    expect(result.valid).toBe(false);
+    expect(result.factors).toContain('weight_missing');
+  });
+  it('handles malformed drug data gracefully', () => {
+    expect(() => checkInteractions('', [], [])).not.toThrow();
+  });
+});
+```
+
+Pass criteria: 100%. A single missed interaction is a patient safety event.
+
+### Anti-Patterns
+
+- Making CDSS checks optional or skippable without documented reason
+- Implementing interaction checks as toast notifications
+- Using `any` types for drug or clinical data
+- Hardcoding interaction pairs instead of using a maintainable data structure
+- Silently catching errors in CDSS engine (must surface failures loudly)
+- Skipping weight-based validation when weight is not available (must block, not pass)
+
+## Examples
+
+### Example 1: Drug Interaction Check
+
+```typescript
+const alerts = checkInteractions('warfarin', ['aspirin', 'metformin'], ['penicillin']);
+// [{ severity: 'critical', pair: ['warfarin', 'aspirin'],
+//    message: 'Increased bleeding risk', recommendation: 'Avoid combination' }]
+```
+
+### Example 2: Dose Validation
+
+```typescript
+const ok = validateDose('paracetamol', 1000, 'oral', 70, 45);
+// { valid: true, suggestedRange: { min: 500, max: 4000, unit: 'mg' } }
+
+const bad = validateDose('paracetamol', 5000, 'oral', 70, 45);
+// { valid: false, message: 'Exceeds absolute max 4000mg' }
+
+const noWeight = validateDose('gentamicin', 300, 'iv');
+// { valid: false, factors: ['weight_missing'] }
+```
+
+### Example 3: NEWS2 Scoring
+
+```typescript
+const result = calculateNEWS2({
+  respiratoryRate: 24, oxygenSaturation: 93, supplementalOxygen: true,
+  temperature: 38.5, systolicBP: 100, heartRate: 110, consciousness: 'voice'
+});
+// { total: 13, risk: 'high', escalation: 'Urgent clinical review. Consider ICU.' }
+```

package/src/harness_context/skills/ecc/healthcare-emr-patterns/LICENSE.ecc

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Affaan Mustafa
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.