agent-actions 0.1.0__tar.gz

agent_actions-0.1.0/.changes/header.tpl.md

@@ -0,0 +1,7 @@
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
+adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html),
+and is generated by [Changie](https://github.com/miniscruff/changie).

agent_actions-0.1.0/.changes/unreleased/Enhancement or New Feature-20260327-081325.yaml

@@ -0,0 +1,3 @@
+kind: Enhancement or New Feature
+body: Add pre-commit hooks, rename wave tests, and fix docs site links
+time: 2026-03-27T08:13:25.135299Z

agent_actions-0.1.0/.changes/unreleased/Enhancement or New Feature-20260327-143000.yaml

@@ -0,0 +1,3 @@
+kind: Enhancement or New Feature
+body: "Add --example flag to agac init for scaffolding projects from bundled examples"
+time: 2026-03-27T14:30:00.000000Z

agent_actions-0.1.0/.changie.yaml

@@ -0,0 +1,32 @@
+changesDir: .changes
+unreleasedDir: unreleased
+headerPath: header.tpl.md
+changelogPath: CHANGELOG.md
+versionExt: md
+versionFormat: '## {{.Version}} - {{.Time.Format "2006-01-02"}}'
+kindFormat: '### {{.Kind}}'
+changeFormat: '* {{.Body}}'
+kinds:
+  - label: Breaking Change
+    auto: major
+  - label: Enhancement or New Feature
+    auto: minor
+  - label: Under the Hood
+    auto: patch
+  - label: Bug Fix
+    auto: patch
+  - label: Security
+    auto: patch
+newlines:
+  afterChangelogHeader: 1
+  beforeChangelogVersion: 1
+  endOfVersion: 1
+envPrefix: CHANGIE_
+
+replacements:
+  - path: pyproject.toml
+    find: '(?m)^version = ".*"'
+    replace: 'version = "{{.VersionNoPrefix}}"'
+  - path: agent_actions/__version__.py
+    find: '(?m)^__version__ = ".*"'
+    replace: '__version__ = "{{.VersionNoPrefix}}"'

agent_actions-0.1.0/.gitignore

@@ -0,0 +1,45 @@
+# Byte-compiled / optimized
+__pycache__/
+*.py[cod]
+*$py.class
+
+# Distribution / packaging
+dist/
+build/
+*.egg-info/
+*.egg
+
+# Virtual environments
+.venv/
+venv/
+
+# Testing
+.pytest_cache/
+.coverage
+htmlcov/
+
+# Type checking / linting
+.mypy_cache/
+.ruff_cache/
+
+# IDEs
+.idea/
+.vscode/
+*.swp
+*.swo
+
+# Environment
+.env
+.env.*
+!.env.example
+
+# OS
+.DS_Store
+Thumbs.db
+
+# Node (docs site)
+node_modules/
+
+# Test artifacts
+MagicMock/
+batch/

agent_actions-0.1.0/.pre-commit-config.yaml

@@ -0,0 +1,21 @@
+repos:
+  - repo: https://github.com/astral-sh/ruff-pre-commit
+    rev: v0.9.10
+    hooks:
+      - id: ruff
+        args: [--fix, --unsafe-fixes]
+      - id: ruff-format
+
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v5.0.0
+    hooks:
+      - id: no-commit-to-branch
+        args: [--branch, main]
+
+  - repo: https://github.com/pre-commit/mirrors-mypy
+    rev: v1.13.0
+    hooks:
+      - id: mypy
+        additional_dependencies: [pydantic, types-PyYAML]
+        args: [--ignore-missing-imports]
+        exclude: ^(examples|tests)/

agent_actions-0.1.0/AGENTS.md

@@ -0,0 +1,296 @@
+# AI Coding Agent Guidelines
+
+These rules define how an AI coding agent should plan, execute, verify, communicate, and recover when working in a real codebase. Optimize for correctness, minimalism, and developer experience.
+
+---
+
+## Project Structure
+
+This project uses the **Agent Manifest Protocol (AMP)** for navigation.
+**[> Open Codebase Map (agent_actions/_MANIFEST.md)](agent_actions/_MANIFEST.md)**
+
+### Navigation Strategy
+1. **Start Here:** Use this file for high-level context.
+2. **Explore:** Follow the `_MANIFEST.md` link above to traverse the codebase structure.
+3. **Inspect:** Read individual `_MANIFEST.md` files in subdirectories to find specific symbols and dependencies.
+4. **Read Code:** Only read source files when you have pinpointed the exact location.
+
+### Development
+- **Install:** `uv sync`
+- **Activate:** `source .venv/bin/activate`
+- **Test:** `pytest`
+- **Lint:** `ruff check .`
+- **Format:** `ruff format .`
+
+### Manifest Maintenance
+Always update `_MANIFEST.md` files when making code changes that add, remove, or modify modules, classes, or functions.
+
+---
+
+## Operating Principles (Non-Negotiable)
+
+- **Correctness over cleverness**: Prefer boring, readable solutions that are easy to maintain.
+- **Smallest change that works**: Minimize blast radius; don't refactor adjacent code unless it meaningfully reduces risk or complexity.
+- **Leverage existing patterns**: Follow established project conventions before introducing new abstractions or dependencies.
+- **Prove it works**: "Seems right" is not done. Validate with tests/build/lint and/or a reliable manual repro.
+- **Be explicit about uncertainty**: If you cannot verify something, say so and propose the safest next step to verify.
+
+---
+
+## Workflow Orchestration
+
+### 1. Plan Mode Default
+- Enter plan mode for any non-trivial task (3+ steps, multi-file change, architectural decision, production-impacting behavior).
+- Include verification steps in the plan (not as an afterthought).
+- If new information invalidates the plan: **stop**, update the plan, then continue.
+- Write a crisp spec first when requirements are ambiguous (inputs/outputs, edge cases, success criteria).
+
+### 2. Subagent Strategy (Parallelize Intelligently)
+- Use subagents to keep the main context clean and to parallelize:
+- repo exploration, pattern discovery, test failure triage, dependency research, risk review.
+- Give each subagent **one focused objective** and a concrete deliverable:
+- "Find where X is implemented and list files + key functions" beats "look around."
+- Merge subagent outputs into a short, actionable synthesis before coding.
+
+### 3. Incremental Delivery (Reduce Risk)
+- Prefer **thin vertical slices** over big-bang changes.
+- Land work in small, verifiable increments:
+- implement → test → verify → then expand.
+- When feasible, keep changes behind:
+- feature flags, config switches, or safe defaults.
+
+### 4. Self-Improvement Loop
+- After any user correction or a discovered mistake:
+- add a new entry to `tasks/lessons.md` capturing:
+- the failure mode, the detection signal, and a prevention rule.
+- Review `tasks/lessons.md` at session start and before major refactors.
+
+### 5. Verification Before "Done"
+- Never mark complete without evidence:
+- tests, lint/typecheck, build, logs, or a deterministic manual repro.
+- Compare behavior baseline vs changed behavior when relevant.
+- Ask: "Would a staff engineer approve this diff and the verification story?"
+
+### 6. Demand Elegance (Balanced)
+- For non-trivial changes, pause and ask:
+- "Is there a simpler structure with fewer moving parts?"
+- If the fix is hacky, rewrite it the elegant way **if** it does not expand scope materially.
+- Do not over-engineer simple fixes; keep momentum and clarity.
+
+### 7. Autonomous Bug Fixing (With Guardrails)
+- When given a bug report:
+- reproduce → isolate root cause → fix → add regression coverage → verify.
+- Do not offload debugging work to the user unless truly blocked.
+- If blocked, ask for **one** missing detail with a recommended default and explain what changes based on the answer.
+
+---
+
+## Task Management (File-Based, Auditable)
+
+1. **Plan First**
+- Write a checklist to `tasks/todo.md` for any non-trivial work.
+- Include "Verify" tasks explicitly (lint/tests/build/manual checks).
+2. **Define Success**
+- Add acceptance criteria (what must be true when done).
+3. **Track Progress**
+- Mark items complete as you go; keep one "in progress" item at a time.
+4. **Checkpoint Notes**
+- Capture discoveries, decisions, and constraints as you learn them.
+5. **Document Results**
+- Add a short "Results" section: what changed, where, how verified.
+6. **Capture Lessons**
+- Update `tasks/lessons.md` after corrections or postmortems.
+
+---
+
+## Communication Guidelines (User-Facing)
+
+### 1. Be Concise, High-Signal
+- Lead with outcome and impact, not process.
+- Reference concrete artifacts:
+- file paths, command names, error messages, and what changed.
+- Avoid dumping large logs; summarize and point to where evidence lives.
+
+### 2. Ask Questions Only When Blocked
+When you must ask:
+- Ask **exactly one** targeted question.
+- Provide a recommended default.
+- State what would change depending on the answer.
+
+### 3. State Assumptions and Constraints
+- If you inferred requirements, list them briefly.
+- If you could not run verification, say why and how to verify.
+
+### 4. Show the Verification Story
+- Always include:
+- what you ran (tests/lint/build), and the outcome.
+- If you didn't run something, give a minimal command list the user can run.
+
+### 5. Avoid "Busywork Updates"
+- Don't narrate every step.
+- Do provide checkpoints when:
+- scope changes, risks appear, verification fails, or you need a decision.
+
+---
+
+## Context Management Strategies (Don't Drown the Session)
+
+### 1. Read Before Write
+- Before editing:
+- locate the authoritative source of truth (existing module/pattern/tests).
+- Prefer small, local reads (targeted files) over scanning the whole repo.
+
+### 2. Keep a Working Memory
+- Maintain a short running "Working Notes" section in `tasks/todo.md`:
+- key constraints, invariants, decisions, and discovered pitfalls.
+- When context gets large:
+- compress into a brief summary and discard raw noise.
+
+### 3. Minimize Cognitive Load in Code
+- Prefer explicit names and direct control flow.
+- Avoid clever meta-programming unless the project already uses it.
+- Leave code easier to read than you found it.
+
+### 4. Control Scope Creep
+- If a change reveals deeper issues:
+- fix only what is necessary for correctness/safety.
+- log follow-ups as TODOs/issues rather than expanding the current task.
+
+---
+
+## Error Handling and Recovery Patterns
+
+### 1. "Stop-the-Line" Rule
+If anything unexpected happens (test failures, build errors, behavior regressions):
+- stop adding features
+- preserve evidence (error output, repro steps)
+- return to diagnosis and re-plan
+
+### 2. Triage Checklist (Use in Order)
+1. **Reproduce** reliably (test, script, or minimal steps).
+2. **Localize** the failure (which layer: UI, API, DB, network, build tooling).
+3. **Reduce** to a minimal failing case (smaller input, fewer steps).
+4. **Fix** root cause (not symptoms).
+5. **Guard** with regression coverage (test or invariant checks).
+6. **Verify** end-to-end for the original report.
+
+### 3. Safe Fallbacks (When Under Time Pressure)
+- Prefer "safe default + warning" over partial behavior.
+- Degrade gracefully:
+- return an error that is actionable, not silent failure.
+- Avoid broad refactors as "fixes."
+
+### 4. Rollback Strategy (When Risk Is High)
+- Keep changes reversible:
+- feature flag, config gating, or isolated commits.
+- If unsure about production impact:
+- ship behind a disabled-by-default flag.
+
+### 5. Instrumentation as a Tool (Not a Crutch)
+- Add logging/metrics only when they:
+- materially reduce debugging time, or prevent recurrence.
+- Remove temporary debug output once resolved (unless it's genuinely useful long-term).
+
+---
+
+## Engineering Best Practices (AI Agent Edition)
+
+### 1. API / Interface Discipline
+- Design boundaries around stable interfaces:
+- functions, modules, components, route handlers.
+- Prefer adding optional parameters over duplicating code paths.
+- Keep error semantics consistent (throw vs return error vs empty result).
+
+### 2. Testing Strategy
+- Add the smallest test that would have caught the bug.
+- Prefer:
+- unit tests for pure logic,
+- integration tests for DB/network boundaries,
+- E2E only for critical user flows.
+- Avoid brittle tests tied to incidental implementation details.
+
+### 3. Type Safety and Invariants
+- Avoid suppressions (`any`, ignores) unless the project explicitly permits and you have no alternative.
+- Encode invariants where they belong:
+- validation at boundaries, not scattered checks.
+
+### 4. Dependency Discipline
+- Do not add new dependencies unless:
+- the existing stack cannot solve it cleanly, and the benefit is clear.
+- Prefer standard library / existing utilities.
+
+### 5. Security and Privacy
+- Never introduce secret material into code, logs, or chat output.
+- Treat user input as untrusted:
+- validate, sanitize, and constrain.
+- Prefer least privilege (especially for DB access and server-side actions).
+
+### 6. Performance (Pragmatic)
+- Avoid premature optimization.
+- Do fix:
+- obvious N+1 patterns, accidental unbounded loops, repeated heavy computation.
+- Measure when in doubt; don't guess.
+
+### 7. Accessibility and UX (When UI Changes)
+- Keyboard navigation, focus management, readable contrast, and meaningful empty/error states.
+- Prefer clear copy and predictable interactions over fancy effects.
+
+### 8. Logging Convention
+
+| Layer | Tool | Level |
+|-------|------|-------|
+| CLI user output | `click.echo()` / `console.print()` | N/A |
+| Operational flow events | `logger.info` | Start, complete, skip |
+| Recoverable failures | `logger.warning` | Retries, fallbacks, degradation |
+| Unrecoverable errors | `logger.error` | Failures that affect output |
+| Debug diagnostics | `logger.debug` | Exception traces, internal state |
+
+Rules:
+- Business logic: `logger = logging.getLogger(__name__)` — never `print()`
+- CLI: `click.echo()` for user output, `logger.*` for operational logging
+- Silent `except: pass` must log at `debug` or `warning` (except destructors and safety utilities)
+- `print()` permitted only in: standalone scripts (`__main__`), docstring examples, dedicated debug handlers
+
+---
+
+## Git and Change Hygiene (If Applicable)
+
+- Keep commits atomic and describable; avoid "misc fixes" bundles.
+- Don't rewrite history unless explicitly requested.
+- Don't mix formatting-only changes with behavioral changes unless the repo standard requires it.
+- Treat generated files carefully:
+- only commit them if the project expects it.
+
+---
+
+## Definition of Done (DoD)
+
+A task is done when:
+- Behavior matches acceptance criteria.
+- Tests/lint/typecheck/build (as relevant) pass or you have a documented reason they were not run.
+- Risky changes have a rollback/flag strategy (when applicable).
+- The code follows existing conventions and is readable.
+- A short verification story exists: "what changed + how we know it works."
+
+---
+
+## Templates
+
+### Plan Template (Paste into `tasks/todo.md`)
+- [ ] Restate goal + acceptance criteria
+- [ ] Locate existing implementation / patterns
+- [ ] Design: minimal approach + key decisions
+- [ ] Implement smallest safe slice
+- [ ] Add/adjust tests
+- [ ] Run verification (lint/tests/build/manual repro)
+- [ ] Summarize changes + verification story
+- [ ] Record lessons (if any)
+
+### Bugfix Template (Use for Reports)
+- Repro steps:
+- Expected vs actual:
+- Root cause:
+- Fix:
+- Regression coverage:
+- Verification performed:
+- Risk/rollback notes:

agent_actions-0.1.0/CHANGELOG.md

@@ -0,0 +1,27 @@
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
+adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html),
+and is generated by [Changie](https://github.com/miniscruff/changie).
+
+## v0.1.0 - 2026-03-27
+
+Initial release.
+
+### Features
+
+- Declarative YAML workflow definition with per-action model, context, and schema configuration
+- Multi-provider LLM support: OpenAI, Anthropic, Google Gemini, Groq, Mistral, Cohere, Ollama
+- DAG-based dependency resolution with automatic parallel execution
+- Batch processing via provider batch APIs for high-throughput workloads
+- Pre-check guards to skip actions before making LLM calls
+- JSON schema validation with automatic reprompt on malformed output
+- Context scoping (`observe` / `drop`) to control token usage per action
+- User-defined functions (UDFs) for custom pre/post-processing logic
+- Parallel consensus pattern (multiple voters + merge)
+- CLI (`agac`) with `run`, `batch`, `init`, `inspect`, `docs`, and `schema` commands
+- LSP server (`agac-lsp`) for editor integration with diagnostics and completions
+- Interactive documentation site via `agac docs serve`
+- Per-action observability: timing, token counts, and structured event logs

agent_actions-0.1.0/CODE_OF_CONDUCT.md

@@ -0,0 +1,92 @@
+
+# Contributor Covenant 3.0 Code of Conduct
+
+## Our Pledge
+
+We pledge to make our community welcoming, safe, and equitable for all.
+
+We are committed to fostering an environment that respects and promotes the dignity, rights, and contributions of all individuals, regardless of characteristics including race, ethnicity, caste, color, age, physical characteristics, neurodiversity, disability, sex or gender, gender identity or expression, sexual orientation, language, philosophy or religion, national or social origin, socio-economic position, level of education, or other status. The same privileges of participation are extended to everyone who participates in good faith and in accordance with this Covenant.
+
+
+## Encouraged Behaviors
+
+While acknowledging differences in social norms, we all strive to meet our community's expectations for positive behavior. We also understand that our words and actions may be interpreted differently than we intend based on culture, background, or native language.
+
+With these considerations in mind, we agree to behave mindfully toward each other and act in ways that center our shared values, including:
+
+1. Respecting the **purpose of our community**, our activities, and our ways of gathering.
+2. Engaging **kindly and honestly** with others.
+3. Respecting **different viewpoints** and experiences.
+4. **Taking responsibility** for our actions and contributions.
+5. Gracefully giving and accepting **constructive feedback**.
+6. Committing to **repairing harm** when it occurs.
+7. Behaving in other ways that promote and sustain the **well-being of our community**.
+
+
+## Restricted Behaviors
+
+We agree to restrict the following behaviors in our community. Instances, threats, and promotion of these behaviors are violations of this Code of Conduct.
+
+1. **Harassment.** Violating explicitly expressed boundaries or engaging in unnecessary personal attention after any clear request to stop.
+2. **Character attacks.** Making insulting, demeaning, or pejorative comments directed at a community member or group of people.
+3. **Stereotyping or discrimination.** Characterizing anyone’s personality or behavior on the basis of immutable identities or traits.
+4. **Sexualization.** Behaving in a way that would generally be considered inappropriately intimate in the context or purpose of the community.
+5. **Violating confidentiality**. Sharing or acting on someone's personal or private information without their permission.
+6. **Endangerment.** Causing, encouraging, or threatening violence or other harm toward any person or group.
+7. Behaving in other ways that **threaten the well-being** of our community.
+
+### Other Restrictions
+
+1. **Misleading identity.** Impersonating someone else for any reason, or pretending to be someone else to evade enforcement actions.
+2. **Failing to credit sources.** Not properly crediting the sources of content you contribute.
+3. **Promotional materials**. Sharing marketing or other commercial content in a way that is outside the norms of the community.
+4. **Irresponsible communication.** Failing to responsibly present content which includes, links or describes any other restricted behaviors.
+
+
+## Reporting an Issue
+
+Tensions can occur between community members even when they are trying their best to collaborate. Not every conflict represents a code of conduct violation, and this Code of Conduct reinforces encouraged behaviors and norms that can help avoid conflicts and minimize harm.
+
+When an incident does occur, it is important to report it promptly. To report a possible violation, please email **conduct@agent-actions.dev** with a description of the incident.
+
+Community Moderators take reports of violations seriously and will make every effort to respond in a timely manner. They will investigate all reports of code of conduct violations, reviewing messages, logs, and recordings, or interviewing witnesses and other participants. Community Moderators will keep investigation and enforcement actions as transparent as possible while prioritizing safety and confidentiality. In order to honor these values, enforcement actions are carried out in private with the involved parties, but communicating to the whole community may be part of a mutually agreed upon resolution.
+
+
+## Addressing and Repairing Harm
+
+**[NOTE: The remedies and repairs outlined below are suggestions based on best practices in code of conduct enforcement. If your community has its own established enforcement process, be sure to edit this section to describe your own policies.]**
+
+If an investigation by the Community Moderators finds that this Code of Conduct has been violated, the following enforcement ladder may be used to determine how best to repair harm, based on the incident's impact on the individuals involved and the community as a whole. Depending on the severity of a violation, lower rungs on the ladder may be skipped.
+
+1) Warning
+   1) Event: A violation involving a single incident or series of incidents.
+   2) Consequence: A private, written warning from the Community Moderators.
+   3) Repair: Examples of repair include a private written apology, acknowledgement of responsibility, and seeking clarification on expectations.
+2) Temporarily Limited Activities
+   1) Event: A repeated incidence of a violation that previously resulted in a warning, or the first incidence of a more serious violation.
+   2) Consequence: A private, written warning with a time-limited cooldown period designed to underscore the seriousness of the situation and give the community members involved time to process the incident. The cooldown period may be limited to particular communication channels or interactions with particular community members.
+   3) Repair: Examples of repair may include making an apology, using the cooldown period to reflect on actions and impact, and being thoughtful about re-entering community spaces after the period is over.
+3) Temporary Suspension
+   1) Event: A pattern of repeated violation which the Community Moderators have tried to address with warnings, or a single serious violation.
+   2) Consequence: A private written warning with conditions for return from suspension. In general, temporary suspensions give the person being suspended time to reflect upon their behavior and possible corrective actions.
+   3) Repair: Examples of repair include respecting the spirit of the suspension, meeting the specified conditions for return, and being thoughtful about how to reintegrate with the community when the suspension is lifted.
+4) Permanent Ban
+   1) Event: A pattern of repeated code of conduct violations that other steps on the ladder have failed to resolve, or a violation so serious that the Community Moderators determine there is no way to keep the community safe with this person as a member.
+   2) Consequence: Access to all community spaces, tools, and communication channels is removed. In general, permanent bans should be rarely used, should have strong reasoning behind them, and should only be resorted to if working through other remedies has failed to change the behavior.
+   3) Repair: There is no possible repair in cases of this severity.
+
+This enforcement ladder is intended as a guideline. It does not limit the ability of Community Managers to use their discretion and judgment, in keeping with the best interests of our community.
+
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public or other spaces. Examples of representing our community include using an official email address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
+
+
+## Attribution
+
+This Code of Conduct is adapted from the Contributor Covenant, version 3.0, permanently available at [https://www.contributor-covenant.org/version/3/0/](https://www.contributor-covenant.org/version/3/0/).
+
+Contributor Covenant is stewarded by the Organization for Ethical Source and licensed under CC BY-SA 4.0. To view a copy of this license, visit [https://creativecommons.org/licenses/by-sa/4.0/](https://creativecommons.org/licenses/by-sa/4.0/)
+
+For answers to common questions about Contributor Covenant, see the FAQ at [https://www.contributor-covenant.org/faq](https://www.contributor-covenant.org/faq). Translations are provided at [https://www.contributor-covenant.org/translations](https://www.contributor-covenant.org/translations). Additional enforcement and community guideline resources can be found at [https://www.contributor-covenant.org/resources](https://www.contributor-covenant.org/resources). The enforcement ladder was inspired by the work of [Mozilla’s code of conduct team](https://github.com/mozilla/inclusion).