codna 0.1.0__py3-none-any.whl

codna/agent-core/vendor/cline/sdk/examples/plugins/agents-squad/package.json

@@ -0,0 +1,39 @@
+{
+	"name": "cline-agent-squad-plugin",
+	"version": "0.1.0",
+	"private": true,
+	"description": "Background Subagents Plugin for Cline",
+	"type": "module",
+	"scripts": {
+		"typecheck": "tsc --noEmit",
+		"clean": "rm -rf node_modules dist"
+	},
+	"exports": {
+		".": "./index.ts"
+	},
+	"cline": {
+		"plugins": [
+			{
+				"paths": [
+					"./index.ts"
+				],
+				"capabilities": [
+					"hooks",
+					"tools"
+				]
+			}
+		]
+	},
+	"peerDependencies": {
+		"@cline/core": "*"
+	},
+	"peerDependenciesMeta": {
+		"@cline/core": {
+			"optional": true
+		}
+	},
+	"dependencies": {
+		"yaml": "^2.8.1",
+		"zod": "^4.1.5"
+	}
+}

codna/agent-core/vendor/cline/sdk/examples/plugins/agents-squad/skills/api-design.md

@@ -0,0 +1,63 @@
+---
+name: api-design
+description: Design clean APIs — REST, RPC, or library interfaces with consistent naming, error handling, and versioning.
+---
+
+# API Design Skill
+
+When designing or reviewing an API (REST, RPC, or library), follow these principles:
+
+## 1. Understand the Consumer
+
+- Who calls this API? (Frontend, other services, CLI, third-party developers)
+- What are the most common operations?
+- What error conditions do consumers need to handle?
+- What's the expected request volume and latency budget?
+
+## 2. Naming Conventions
+
+- Use consistent, predictable names across all endpoints/methods.
+- Nouns for resources, verbs for actions: `GET /users`, `POST /users/:id/activate`.
+- For library APIs: verb-first for actions (`createUser`, `deleteSession`), noun-first for accessors (`getUserById`).
+- Avoid abbreviations unless universally understood (`id`, `url`, `api`).
+- Be specific: `getActiveUserCount()` not `getCount()`.
+
+## 3. Input Design
+
+- Accept the minimum required input. Optional fields should have sensible defaults.
+- Use typed schemas (Zod, JSON Schema) for validation at the boundary.
+- Reject invalid input early with clear error messages.
+- For REST: use path params for identity (`/users/:id`), query params for filtering (`?status=active`), body for creation/mutation.
+- For libraries: prefer options objects over long parameter lists.
+
+## 4. Output Design
+
+- Return consistent shapes. Every endpoint should return the same envelope structure.
+- Include enough context for the consumer to act without a follow-up call.
+- Paginate list endpoints. Always include `total`, `limit`, `offset` or cursor.
+- Use ISO 8601 for dates, consistent casing (camelCase or snake_case, not both).
+
+## 5. Error Handling
+
+- Use standard HTTP status codes (REST) or typed error codes (RPC/library).
+- Every error response must include: error code, human-readable message, and request ID.
+- Distinguish client errors (4xx / validation) from server errors (5xx / internal).
+- Never expose internal details (stack traces, SQL, file paths) in production errors.
+- Document every error code the consumer might receive.
+
+## 6. Versioning & Evolution
+
+- Version the API from day one (`/v1/`, header-based, or semver for libraries).
+- Additive changes (new fields, new endpoints) are non-breaking.
+- Removing or renaming fields is breaking — deprecate first, remove in next major version.
+- Document breaking changes in a changelog.
+
+## 7. Documentation
+
+For each endpoint or method, document:
+1. Purpose (one sentence).
+2. Input parameters with types and constraints.
+3. Output shape with example.
+4. Error codes and when they occur.
+5. Authentication/authorization requirements.
+6. Rate limits if applicable.

codna/agent-core/vendor/cline/sdk/examples/plugins/agents-squad/skills/code-review.md

@@ -0,0 +1,61 @@
+---
+name: code-review
+description: Structured code review — security, correctness, performance, and maintainability analysis with severity-ranked findings.
+---
+
+# Code Review Skill
+
+When reviewing code, follow this structured process:
+
+## 1. Scope the Review
+
+- Identify all changed files and their relationships.
+- Understand the intent: what problem does this change solve?
+- Note any files that *should* have changed but didn't.
+
+## 2. Correctness Pass
+
+- Trace data flow through every changed path.
+- Check edge cases: null/undefined, empty collections, boundary values.
+- Verify error handling: are errors caught, propagated, and surfaced correctly?
+- Look for off-by-one errors, race conditions, and state mutation bugs.
+- Confirm types match runtime expectations (especially `any`, casts, and assertions).
+
+## 3. Security Pass
+
+- Flag unvalidated user input reaching sensitive operations (SQL, shell, file paths, URLs).
+- Check authentication and authorization on every new endpoint or handler.
+- Look for secrets in code, logs, or error messages.
+- Verify CORS, CSP, and other security headers if applicable.
+- Check for timing attacks in comparison operations.
+
+## 4. Performance Pass
+
+- Identify N+1 queries, unbounded loops, and unnecessary allocations.
+- Check for missing indexes on new database queries.
+- Look for blocking operations on hot paths.
+- Verify pagination and limits on list operations.
+- Note any operations that scale poorly with input size.
+
+## 5. Maintainability Pass
+
+- Evaluate naming: do names communicate intent?
+- Check abstraction boundaries: is coupling introduced or reduced?
+- Look for duplicated logic that should be shared.
+- Verify tests cover the new behavior and edge cases.
+- Note missing documentation for public APIs.
+
+## 6. Report Format
+
+Organize findings by severity:
+
+- **Critical**: Must fix before merge. Bugs, security issues, data loss risks.
+- **Major**: Should fix. Design problems, missing error handling, performance issues.
+- **Minor**: Worth noting. Style, naming, minor improvements.
+- **Positive**: Non-obvious good decisions worth calling out (keep brief).
+
+For each finding, include:
+1. File and line reference
+2. What the issue is
+3. Why it matters
+4. Suggested fix (concrete, not vague)

codna/agent-core/vendor/cline/sdk/examples/plugins/agents-squad/skills/debugging.md

@@ -0,0 +1,62 @@
+---
+name: debugging
+description: Systematic debugging — reproduce, isolate, diagnose, and fix bugs with root-cause analysis.
+---
+
+# Debugging Skill
+
+When debugging an issue, follow this systematic process:
+
+## 1. Understand the Bug
+
+- Read the error message, stack trace, and any logs carefully.
+- Reproduce the issue. If you can't reproduce it, you can't verify a fix.
+- Identify the expected behavior vs. actual behavior.
+- Note the environment: OS, runtime version, configuration, input data.
+
+## 2. Isolate
+
+Narrow the scope using binary search:
+
+- **Which file?** Trace the stack trace or data flow to the origin.
+- **Which function?** Add logging or breakpoints at entry/exit of suspect functions.
+- **Which line?** Check variable values before and after the suspect operation.
+- **Which input?** Find the minimal input that triggers the bug.
+
+### Common Isolation Techniques
+- Comment out code blocks to find the trigger.
+- Add temporary `console.log` / `console.error` with labeled values.
+- Use a debugger to step through execution.
+- Write a minimal reproduction test case.
+
+## 3. Diagnose
+
+Once isolated, determine the root cause:
+
+### Common Root Causes
+- **Type mismatch**: Runtime value doesn't match expected type (null, undefined, wrong shape).
+- **State mutation**: Shared state modified unexpectedly by another code path.
+- **Race condition**: Timing-dependent behavior in async or concurrent code.
+- **Off-by-one**: Loop bounds, array indexing, or string slicing errors.
+- **Missing error handling**: Unhandled promise rejection, uncaught exception, or swallowed error.
+- **Stale reference**: Closure capturing a variable that changes, or cached data that's outdated.
+- **Environment difference**: Works locally but fails in CI/production due to config, permissions, or versions.
+
+Ask: "Why did this happen?" at least twice to get past symptoms to the root cause.
+
+## 4. Fix
+
+- Write a test that fails because of the bug (before fixing it).
+- Make the minimal change that fixes the root cause.
+- Verify the test now passes.
+- Check for the same pattern elsewhere in the codebase.
+- Run the full test suite to confirm no regressions.
+
+## 5. Report
+
+Document:
+- What the bug was (symptoms and root cause).
+- How it was reproduced.
+- What the fix was and why it's correct.
+- Whether the same pattern exists elsewhere.
+- What test was added to prevent regression.

codna/agent-core/vendor/cline/sdk/examples/plugins/agents-squad/skills/documentation.md

@@ -0,0 +1,83 @@
+---
+name: documentation
+description: Write clear technical documentation — READMEs, API docs, architecture guides, and inline comments.
+---
+
+# Documentation Skill
+
+When writing or improving documentation, follow these principles:
+
+## 1. Know Your Audience
+
+- **README**: New developers evaluating or onboarding to the project.
+- **API docs**: Developers integrating with the API.
+- **Architecture docs**: Team members understanding system design.
+- **Inline comments**: Future maintainers (including yourself in 6 months).
+
+## 2. README Structure
+
+A good README answers these questions in order:
+
+1. **What is this?** One paragraph. What problem does it solve?
+2. **Quick start**: The fastest path from zero to working. Copy-pasteable commands.
+3. **Installation**: Prerequisites, install steps, configuration.
+4. **Usage**: Common use cases with code examples.
+5. **API reference**: If small enough; otherwise link to generated docs.
+6. **Configuration**: All options with defaults and descriptions.
+7. **Contributing**: How to set up dev environment, run tests, submit changes.
+8. **License**: One line.
+
+## 3. API Documentation
+
+For each endpoint, function, or method:
+
+```
+### functionName(param1, param2, options?)
+
+Brief description of what it does.
+
+**Parameters:**
+- `param1` (string, required) — What this parameter controls.
+- `param2` (number, optional, default: 10) — What this parameter controls.
+- `options.verbose` (boolean, default: false) — Enable verbose output.
+
+**Returns:** `Promise<Result>` — Description of the return value.
+
+**Throws:**
+- `ValidationError` — When input is invalid.
+- `NotFoundError` — When the resource doesn't exist.
+
+**Example:**
+```ts
+const result = await functionName("input", 5);
+```
+```
+
+## 4. Architecture Documentation
+
+- Start with a high-level diagram (Mermaid, ASCII, or image).
+- Describe each component's responsibility in one sentence.
+- Document data flow for the most important operations.
+- List key design decisions and their rationale.
+- Note known limitations and planned improvements.
+
+## 5. Inline Comments
+
+Write comments that explain **why**, not **what**:
+
+- ✅ `// Retry 3 times because the upstream API has transient 503s during deploys`
+- ❌ `// Retry 3 times`
+- ✅ `// Sort descending so the most recent entry is first for the dashboard`
+- ❌ `// Sort the array`
+
+Never comment obvious code. If code needs a comment to explain what it does, refactor the code to be self-explanatory first.
+
+## 6. Quality Checklist
+
+Before finalizing documentation:
+- [ ] All code examples compile and run.
+- [ ] No broken links.
+- [ ] Consistent formatting and terminology.
+- [ ] No outdated information from previous versions.
+- [ ] Spelling and grammar checked.
+- [ ] Table of contents for documents longer than 3 sections.

codna/agent-core/vendor/cline/sdk/examples/plugins/agents-squad/skills/migration.md

@@ -0,0 +1,77 @@
+---
+name: migration
+description: Plan and execute data or schema migrations — database, config, and API migrations with rollback strategies.
+---
+
+# Migration Skill
+
+When planning or executing a migration (database schema, data transformation, config format, or API version), follow this process:
+
+## 1. Assess Scope
+
+- What is being migrated? (Schema, data, config, API contract)
+- How much data is affected? (Row count, file count, consumer count)
+- What is the downtime tolerance? (Zero-downtime, maintenance window, offline)
+- What systems depend on the current state?
+
+## 2. Plan the Migration
+
+### Strategy Selection
+
+- **Expand-Contract** (preferred for zero-downtime):
+  1. Expand: Add new columns/fields/endpoints alongside old ones.
+  2. Migrate: Backfill data, update consumers to use new format.
+  3. Contract: Remove old columns/fields/endpoints.
+
+- **Blue-Green**: Run old and new versions in parallel, switch traffic.
+- **Big Bang**: Take the system offline, migrate, bring it back. Only for small datasets or when downtime is acceptable.
+
+### Rollback Plan
+
+Every migration must have a rollback plan before execution:
+- Can the migration be reversed with a down migration?
+- Is there a backup of the current state?
+- What is the point of no return (if any)?
+- How long does rollback take?
+
+## 3. Write the Migration
+
+### Database Migrations
+- One migration file per logical change.
+- Include both `up` and `down` functions.
+- Use transactions where the database supports them.
+- Never modify data and schema in the same migration.
+- Test with production-scale data volumes (not just empty tables).
+
+### Data Migrations
+- Process in batches to avoid memory exhaustion and lock contention.
+- Log progress (processed X of Y records).
+- Handle partial failures: make migrations idempotent so they can be re-run.
+- Validate data after migration (row counts, checksums, spot checks).
+
+### Config Migrations
+- Read old format, write new format, validate round-trip.
+- Preserve comments and ordering where possible.
+- Provide a CLI command or script users can run.
+
+## 4. Test
+
+- Run the migration on a copy of production data.
+- Verify the application works correctly after migration.
+- Run the rollback and verify the application works on the old state.
+- Test the migration under load if zero-downtime is required.
+
+## 5. Execute
+
+- Take a backup before starting.
+- Run the migration with monitoring (error rates, latency, disk usage).
+- Verify success criteria immediately after completion.
+- Keep the rollback plan ready for the agreed monitoring period.
+
+## 6. Report
+
+Document:
+- What was migrated and why.
+- Duration and any issues encountered.
+- Verification results.
+- Rollback status (available / expired / not needed).

codna/agent-core/vendor/cline/sdk/examples/plugins/agents-squad/skills/refactoring.md

@@ -0,0 +1,58 @@
+---
+name: refactoring
+description: Safe, incremental refactoring — extract, rename, simplify, and restructure code without changing behavior.
+---
+
+# Refactoring Skill
+
+When refactoring code, follow this disciplined process:
+
+## 1. Establish Safety Net
+
+Before changing anything:
+- Confirm existing tests pass. If no tests exist, write characterization tests first.
+- Identify all callers and consumers of the code being refactored.
+- Document the current behavior as your contract — refactoring must not change it.
+
+## 2. Plan the Refactoring
+
+Choose the smallest transformation that makes progress:
+
+### Common Refactorings
+- **Extract function**: Pull a block into a named function when it has a clear purpose.
+- **Inline function**: Remove a function that adds indirection without clarity.
+- **Rename**: Change names to communicate intent (variables, functions, types, files).
+- **Extract type/interface**: Pull inline types into named declarations.
+- **Simplify conditionals**: Replace nested if/else with early returns, guard clauses, or lookup tables.
+- **Remove dead code**: Delete unreachable code, unused imports, and commented-out blocks.
+- **Reduce parameters**: Group related parameters into an options object.
+- **Split module**: Break a large file into focused modules with clear responsibilities.
+
+### Decision Criteria
+- Does this reduce cognitive load for the next reader?
+- Does this make the code easier to test?
+- Does this reduce the blast radius of future changes?
+- If none of the above: don't refactor it.
+
+## 3. Execute Incrementally
+
+- Make one refactoring at a time.
+- After each change, verify tests still pass.
+- Commit or checkpoint after each successful step.
+- If a step breaks something, revert it and try a smaller step.
+
+## 4. Verify
+
+After all changes:
+- Run the full test suite.
+- Check that all callers still compile and work correctly.
+- Verify no behavior has changed (same inputs → same outputs).
+- Review the diff: is the code genuinely simpler, or just different?
+
+## 5. Report
+
+Summarize:
+- What was refactored and why.
+- Which files changed.
+- Any behavior that looks different but is equivalent.
+- Anything left incomplete or worth refactoring next.

codna/agent-core/vendor/cline/sdk/examples/plugins/agents-squad/skills/test-generation.md

@@ -0,0 +1,76 @@
+---
+name: test-generation
+description: Generate comprehensive test suites — unit, integration, and edge-case coverage with proper mocking strategies.
+---
+
+# Test Generation Skill
+
+When generating tests, follow this process:
+
+## 1. Analyze the Target
+
+- Read the source code thoroughly before writing any tests.
+- Identify the public API surface: exports, parameters, return types.
+- Map dependencies that need mocking or stubbing.
+- List the behavioral contracts: what must always be true?
+
+## 2. Plan Test Cases
+
+Organize tests into categories:
+
+### Happy Path
+- Standard inputs produce expected outputs.
+- All documented use cases work correctly.
+
+### Edge Cases
+- Empty inputs (null, undefined, empty string, empty array, 0).
+- Boundary values (min/max integers, very long strings, single-element arrays).
+- Unicode and special characters in string inputs.
+
+### Error Cases
+- Invalid input types and shapes.
+- Missing required fields.
+- Network/IO failures (timeouts, connection refused, permission denied).
+- Concurrent access and race conditions where applicable.
+
+### Integration Points
+- Verify correct interaction with dependencies.
+- Check that mocks match the real interface.
+- Test retry and fallback behavior.
+
+## 3. Write Tests
+
+Follow these conventions:
+
+```
+describe("ModuleName", () => {
+  describe("functionName", () => {
+    it("should [expected behavior] when [condition]", () => {
+      // Arrange — set up inputs and mocks
+      // Act — call the function
+      // Assert — verify the result
+    });
+  });
+});
+```
+
+### Mocking Strategy
+- Mock at the boundary (network, filesystem, database), not internal functions.
+- Use dependency injection where possible instead of module mocking.
+- Verify mock call counts and arguments, not just return values.
+- Reset mocks between tests to prevent state leakage.
+
+### Assertions
+- Assert on specific values, not just truthiness.
+- Check error messages and types, not just that an error was thrown.
+- Use snapshot tests sparingly — only for stable, complex output.
+- Verify side effects (files written, events emitted, logs produced).
+
+## 4. Quality Checks
+
+Before finalizing:
+- Run the tests and confirm they pass.
+- Verify each test fails when the behavior it tests is broken.
+- Check that tests are independent and can run in any order.
+- Ensure test names describe the behavior, not the implementation.
+- Remove any redundant tests that don't add coverage.

codna/agent-core/vendor/cline/sdk/examples/plugins/agents-squad/tsconfig.json

@@ -0,0 +1,4 @@
+{
+	"extends": "../../tsconfig.json",
+	"include": ["index.ts"]
+}

codna/agent-core/vendor/cline/sdk/examples/plugins/automation-events.ts

@@ -0,0 +1,91 @@
+/**
+ * Automation Event Plugin Example
+ *
+ * Shows how a plugin can declare normalized event types and emit events into
+ * ClineCore automation without importing cron internals.
+ *
+ * Local demo:
+ *   cline plugin install https://github.com/cline/cline/blob/main/sdk/examples/plugins/automation-events.ts --cwd .
+ *   mkdir -p .cline/cron/events
+ *   cp examples/cron/events/local-plugin-event.event.md .cline/cron/events/local-plugin-event.event.md
+ *   perl -0pi -e "s#/absolute/path/to/repo#$PWD#g" .cline/cron/events/local-plugin-event.event.md
+ *   CLINE_LOCAL_EVENT_INTERVAL_MS=2000 cline -i "wait for the plugin event"
+ */
+
+import type { AgentPlugin } from "@cline/core";
+
+const stopLocalEmitters = new Map<string, () => void>();
+
+function emitterKey(sessionId: string | undefined): string | undefined {
+	return sessionId?.trim() || undefined;
+}
+
+export const plugin: AgentPlugin = {
+	name: "local-automation-events",
+	manifest: {
+		capabilities: ["automationEvents"],
+	},
+
+	setup(api, ctx) {
+		api.registerAutomationEventType({
+			eventType: "local.plugin_event",
+			source: "local-plugin",
+			description: "Local normalized event emitted by a plugin",
+			attributesSchema: {
+				type: "object",
+				properties: {
+					topic: { type: "string" },
+				},
+				required: ["topic"],
+			},
+			examples: [
+				{
+					eventId: "local-plugin-demo-1",
+					eventType: "local.plugin_event",
+					source: "local-plugin",
+					subject: "plugin-demo",
+					occurredAt: "2026-04-24T10:00:00.000Z",
+					attributes: { topic: "plugin-demo" },
+				},
+			],
+		});
+		ctx.logger?.log("local automation event source registered", {
+			sessionId: ctx.session?.sessionId,
+			client: ctx.client?.name,
+		});
+
+		const intervalMs = Number(process.env.CLINE_LOCAL_EVENT_INTERVAL_MS ?? 0);
+		if (!ctx.automation || !Number.isFinite(intervalMs) || intervalMs <= 0) {
+			return;
+		}
+
+		const key = emitterKey(ctx.session?.sessionId);
+		if (!key) {
+			ctx.logger?.log(
+				"local automation event emitter disabled; setup context has no session id",
+				{ severity: "warn" },
+			);
+			return;
+		}
+		stopLocalEmitters.get(key)?.();
+
+		const timer = setInterval(() => {
+			void ctx.automation?.ingestEvent({
+				eventId: `local-plugin-${Date.now()}`,
+				eventType: "local.plugin_event",
+				source: "local-plugin",
+				subject: "plugin-demo",
+				occurredAt: new Date().toISOString(),
+				dedupeKey: "local-plugin:plugin-demo",
+				attributes: { topic: "plugin-demo" },
+				payload: {
+					message: "Hello from a plugin-emitted automation event.",
+				},
+			});
+		}, intervalMs);
+
+		stopLocalEmitters.set(key, () => clearInterval(timer));
+	},
+};
+
+export default plugin;