open-codev-workflow 0.1.4__tar.gz → 0.1.7__tar.gz

{open_codev_workflow-0.1.4 → open_codev_workflow-0.1.7}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: open-codev-workflow
-Version: 0.1.4
+Version: 0.1.7
 Summary: Human-guided AI software delivery for real repositories.
 Author: Martin Urban
 License-Expression: BSD-3-Clause
@@ -91,7 +91,7 @@ The development workflow for building a wheel is documented below.
 ### Initialize a repository
 
 ```shell
-codev init --target ../my-project --platform all
+codev init --target ../my-project --agent-platform all
 codev check --target ../my-project
 ```
 
@@ -202,27 +202,37 @@ my-project/
 ├── AGENTS.md                         # a managed policy block; local text survives
 ├── .agents/skills/                   # lifecycle, PR, and specialist review skills
 ├── .agents/agents/                   # Antigravity subagents
+├── .codex/agents/                     # Codex orchestrator, builder, reviewer
 ├── .opencode/agents/                 # orchestrator, builder, reviewer
 ├── .opencode/opencode.json           # safely merged; existing agent settings survive
 ├── .junie/agents/                    # Junie subagents
-├── docs/                             # workflow, prompts, handbooks, cookbook
+├── docs/                             # AI guidance and human delivery guide
 ├── evals/development-workflow/       # behavioral scenarios
 ├── scripts/                          # deterministic validators
 └── .codev/lock.json                # installed version and source hashes
 ```
 
-Use `--platform codex` to omit the OpenCode, Junie, and Antigravity adapters.
-Use `--platform opencode`, `--platform junie`, or `--platform antigravity` to
-select one adapter, or use `--platform all` for every supported platform. Core
+Use `--agent-platform codex` to omit the OpenCode, Junie, and Antigravity adapters.
+The Codex adapter installs TOML agents under `.codex/agents/`.
+Use `--agent-platform opencode`, `--agent-platform junie`, or
+`--agent-platform antigravity` to select one adapter, or use
+`--agent-platform all` for every supported platform. Core
 skills and human/AI workflow references are installed for every platform.
 
+The human delivery guide is installed at `docs/for-human/development-guide.md`.
+The cookbook, prompt templates, and detailed handbooks are maintained as
+dedicated Wiki pages.
+
 To add an adapter to an existing installation, pass it to `update`, for example
-`codev update --platform junie`. Use `diff --platform junie` to preview the
+`codev update --agent-platform junie`. Use `diff --agent-platform junie` to preview the
 platform expansion first.
 
 The Antigravity adapter follows its official workspace location:
 `.agents/agents/<name>.md`.
 
+The Codex adapter follows its official workspace location:
+`.codex/agents/<name>.toml`.
+
 ## Design principles
 
 1. **Local at use time.** Agents read ordinary files in the target repository.

{open_codev_workflow-0.1.4 → open_codev_workflow-0.1.7}/README.md

@@ -62,7 +62,7 @@ The development workflow for building a wheel is documented below.
 ### Initialize a repository
 
 ```shell
-codev init --target ../my-project --platform all
+codev init --target ../my-project --agent-platform all
 codev check --target ../my-project
 ```
 
@@ -173,27 +173,37 @@ my-project/
 ├── AGENTS.md                         # a managed policy block; local text survives
 ├── .agents/skills/                   # lifecycle, PR, and specialist review skills
 ├── .agents/agents/                   # Antigravity subagents
+├── .codex/agents/                     # Codex orchestrator, builder, reviewer
 ├── .opencode/agents/                 # orchestrator, builder, reviewer
 ├── .opencode/opencode.json           # safely merged; existing agent settings survive
 ├── .junie/agents/                    # Junie subagents
-├── docs/                             # workflow, prompts, handbooks, cookbook
+├── docs/                             # AI guidance and human delivery guide
 ├── evals/development-workflow/       # behavioral scenarios
 ├── scripts/                          # deterministic validators
 └── .codev/lock.json                # installed version and source hashes
 ```
 
-Use `--platform codex` to omit the OpenCode, Junie, and Antigravity adapters.
-Use `--platform opencode`, `--platform junie`, or `--platform antigravity` to
-select one adapter, or use `--platform all` for every supported platform. Core
+Use `--agent-platform codex` to omit the OpenCode, Junie, and Antigravity adapters.
+The Codex adapter installs TOML agents under `.codex/agents/`.
+Use `--agent-platform opencode`, `--agent-platform junie`, or
+`--agent-platform antigravity` to select one adapter, or use
+`--agent-platform all` for every supported platform. Core
 skills and human/AI workflow references are installed for every platform.
 
+The human delivery guide is installed at `docs/for-human/development-guide.md`.
+The cookbook, prompt templates, and detailed handbooks are maintained as
+dedicated Wiki pages.
+
 To add an adapter to an existing installation, pass it to `update`, for example
-`codev update --platform junie`. Use `diff --platform junie` to preview the
+`codev update --agent-platform junie`. Use `diff --agent-platform junie` to preview the
 platform expansion first.
 
 The Antigravity adapter follows its official workspace location:
 `.agents/agents/<name>.md`.
 
+The Codex adapter follows its official workspace location:
+`.codex/agents/<name>.toml`.
+
 ## Design principles
 
 1. **Local at use time.** Agents read ordinary files in the target repository.

{open_codev_workflow-0.1.4 → open_codev_workflow-0.1.7}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "open-codev-workflow"
-version = "0.1.4"
+version = "0.1.7"
 description = "Human-guided AI software delivery for real repositories."
 readme = "README.md"
 requires-python = ">=3.11"
@@ -56,11 +56,13 @@ codev_workflow = [
   "bundle/.agents/skills/*/references/*",
   "bundle/.agents/skills/*/scripts/*",
   "bundle/.agents/agents/*.md",
+  "bundle/.codex/agents/*.toml",
   "bundle/.opencode/agents/*.md",
   "bundle/.junie/agents/*.md",
   "bundle/.junie/commands/*.md",
   "bundle/docs/*.md",
   "bundle/docs/for-ai/*.md",
+  "bundle/docs/for-human/*.md",
   "bundle/docs/handbooks/*.md",
   "bundle/evals/development-workflow/*.json",
   "bundle/scripts/*.py",

{open_codev_workflow-0.1.4 → open_codev_workflow-0.1.7}/src/codev_workflow/__init__.py

@@ -2,4 +2,4 @@
 
 __all__ = ["__version__"]
 
-__version__ = "0.1.4"
+__version__ = "0.1.7"

{open_codev_workflow-0.1.4 → open_codev_workflow-0.1.7}/src/codev_workflow/bundle/.agents/agents/builder.md

@@ -13,7 +13,7 @@ tools:
 ---
 
 Implement exactly one bounded work item delegated by the orchestrator. Follow
-`AGENTS.md`, `docs/for-ai/WORKFLOW-AGENTS.md`, and `build-change`. Treat the
+`AGENTS.md`, `docs/for-ai/ai-agent-guidelines.md`, and `build-change`. Treat the
 accepted implementation plan and its cited brief/specification/design/API as
 authority; do not redesign them to make coding easier.
 

{open_codev_workflow-0.1.4 → open_codev_workflow-0.1.7}/src/codev_workflow/bundle/.agents/agents/orchestrator.md

@@ -8,7 +8,7 @@ commandExecutionPolicy: sandbox
 ---
 
 Act as the human's primary engineering partner. Follow `AGENTS.md`,
-`docs/for-ai/WORKFLOW-AGENTS.md`, and the applicable repository skills. Present
+`docs/for-ai/ai-agent-guidelines.md`, and the applicable repository skills. Present
 the work as `Understand`, `Build`, `Review`, or `Ship` and select the lightest
 safe path without requiring the human to know skill names.
 

open_codev_workflow-0.1.7/src/codev_workflow/bundle/.agents/skills/audit-google-python-style/SKILL.md

@@ -0,0 +1,156 @@
+---
+name: audit-google-python-style
+description: Audit Python code against the Google Python Style Guide using this repository's Ruff and pymake toolchain plus supplemental analysis, then propose a short grouped remediation plan for explicit human approval before modifying approved source files. Invoke only when the user explicitly requests this audit or invokes $audit-google-python-style. Do not use for ordinary code reviews, pull-request reviews, linting, or implementation tasks.
+---
+
+# Audit Google Python Style
+
+Perform a specialist Google Python Style audit with Ruff and `pymake` as the
+deterministic baseline. This skill has two explicit phases: plan, then apply
+after approval.
+
+## Invocation boundary
+
+Use this skill only for an explicit request such as:
+
+```text
+$audit-google-python-style
+Audit the Python codebase and propose approved style fixes.
+```
+
+Do not invoke it implicitly as part of `review-change`, `clean-code-review`,
+`pr-review`, a normal code review, or a generic linting request.
+
+Invoking the skill is not approval to modify code. Keep the audit and plan
+phase read-only. Require a separate affirmative human response to the exact
+plan before entering the apply phase.
+
+## Tooling policy
+
+The attached guide mentions Pylint, but this repository deliberately uses Ruff.
+Never invoke, install, configure, or require Pylint. Use the repository wrapper:
+
+```powershell
+.\pymake.bat lint
+.\pymake.bat format dry_run=true
+.\pymake.bat check_types
+```
+
+Use `pymake` rather than invoking Ruff, formatters, or type checkers directly.
+The supplemental standard-library checker is the only extra command because no
+existing `pymake` task wraps it.
+
+## Phase A: audit and approval plan
+
+1. Read repository instructions, `ruff.toml`, `pyproject.toml`, `pyrefly.toml`,
+   package-specific configurations, generated-code conventions, local
+   exceptions, and the current working-tree state.
+2. Define the in-scope `.py` files. Include tests unless explicitly excluded.
+   Exclude dependencies, caches, build output, vendored code, generated code,
+   and `.agents` only with repository evidence.
+3. Run the deterministic `pymake` checks before making judgments.
+4. Run `scripts/check_google_rules.py` for each Python package.
+5. Perform the agent judgment pass over imports, naming, documentation,
+   exceptions, resources, global state, type annotations, and consistency.
+6. Produce a short remediation plan grouped by source-file collection and rule
+   family. Include:
+   - approved scope and excluded files;
+   - grouped files or directories;
+   - exact style changes proposed;
+   - whether each change is Ruff-assisted or manual;
+   - non-goals and behavior-preservation constraints; and
+   - post-approval validation commands.
+7. Stop and ask the human to approve, reject, or revise this exact plan. Do not
+   edit files, run `pymake` write-mode format/lint fixes, or apply automated
+   changes before approval.
+
+If the plan depends on missing scope, a project-policy decision, uncertain
+generated-code status, or a behavior/public-API/architecture change, ask for
+clarification instead of silently expanding the plan.
+
+## Strict documentation contract
+
+Treat documentation as a style requirement for every documentable symbol,
+whether it is public or private. This includes modules, functions, async
+functions, classes, methods, constructors, properties, and other named
+callables. Do not exempt a private or internal symbol merely because its name
+starts with an underscore. Generated code is excluded only when the repository
+provides evidence that it is generated and out of scope.
+
+Every docstring must contain a concise summary sentence on its first line,
+terminated as a complete sentence. For functions and methods, use Google
+Python docstring sections as applicable:
+
+- `Args:` describes every meaningful parameter, including keyword-only,
+  variadic, optional, and private parameters; `self` and `cls` do not need
+  entries.
+- `Returns:` describes every returned value when the callable returns a value.
+- `Yields:` describes yielded values for generators instead of `Returns:`.
+- `Raises:` describes exceptions that are part of the callable's contract.
+
+Do not accept an empty docstring, a placeholder, a name restatement, or a
+summary without required parameter or return documentation. A callable with no
+meaningful parameters does not need an `Args:` section, and a callable that
+only returns `None` does not need `Returns:`, but its summary must still
+describe the behavior. Missing docstrings or missing applicable sections are
+style fixes for the approval plan unless their wording requires a human API or
+behavior decision.
+
+## Phase B: approved remediation
+
+Enter this phase only after explicit approval of the plan. Treat approval as
+limited to the named files, rule families, and non-goals.
+
+1. Re-check the working tree and re-audit the approved scope. If relevant files
+   changed since the plan, stop and present an updated plan.
+2. Apply only the approved style changes. Preserve runtime behavior, public
+   APIs, tests, and unrelated user changes. Do not alter dependencies,
+   configuration, or generated sources unless explicitly approved.
+3. Use Ruff's formatter and safe fixes through the repository wrapper when the
+   approved scope covers the formatter's full target. For a partial scope,
+   make targeted edits and use `pymake` check-only validation to avoid changing
+   unapproved files.
+4. Make remaining documentation, import, exception, type, naming, and design
+   corrections manually.
+5. Re-run `pymake lint`, `pymake format dry_run=true`, `pymake check_types`, and
+   the supplemental checker. Run tests when edits could affect behavior.
+6. Inspect the exact diff for scope expansion, accidental behavior changes,
+   weakened tests, and formatter churn.
+7. Report applied changes, validation evidence, residual findings, and any
+   items that require a new approval. Do not merge, commit, or release.
+
+## Supplemental checks
+
+The checker identifies relative and wildcard imports, semicolons, explicit
+line continuations, type comments, Pylint suppressions, `typing.Text`, legacy
+typing aliases, broad exception handlers, assertions outside tests, missing or
+incomplete docstrings for public and private documentable symbols, mutable
+module/class state, nested definitions, lambdas, long functions, long lines,
+malformed TODO comments, syntax errors, and unreadable source files.
+
+Use Python's standard-library `ast` and `tokenize` modules. Hard syntactic
+violations exit non-zero; judgment items are review findings until the agent
+decides whether the guide and repository context establish a violation.
+
+## Style judgment
+
+Apply the guide's normative language precisely. Treat recommendations as
+context-sensitive unless Ruff, the type checker, or local policy makes them
+mandatory. Review module structure, docstring completeness and quality,
+comments, exception design, resource lifetime and context managers,
+comprehensions, decorators, generators, properties, logging, error messages,
+TODO context, `__main__` guards, function size, annotations, `None` handling,
+generics, and local consistency. The documentation contract above is an
+explicit project audit policy and applies to private symbols as well as public
+ones. Do not turn Pylint-specific instructions into requirements for this
+Ruff-based repository.
+
+## Plan and completion reports
+
+The plan report must end with `APPROVAL REQUIRED` unless no changes are needed.
+The apply report must include exact commands and results, approved scope,
+changed files, residual findings, and one verdict: `COMPLETED`, `PARTIALLY
+COMPLETED`, or `CLARIFICATION REQUIRED`.
+
+Never claim compliance solely because Ruff passes. Human approval authorizes
+only the approved remediation plan and never authorizes merge or release.

open_codev_workflow-0.1.7/src/codev_workflow/bundle/.agents/skills/audit-google-python-style/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "Google Python Style Audit"
+  short_description: "Dedicated Google Python conformance audit"
+  default_prompt: "Use $audit-google-python-style to audit this Python codebase and propose approved style fixes."
+
+policy:
+  allow_implicit_invocation: false

open_codev_workflow-0.1.7/src/codev_workflow/bundle/.agents/skills/audit-google-python-style/references/check-matrix.md

@@ -0,0 +1,49 @@
+# Google Python Audit Check Matrix
+
+## Authority
+
+Use the attached Google Python Style Guide as the primary authority. Its major
+areas are Python language rules, imports and packages, exceptions, mutable
+global state, nested definitions, comprehensions, iterators, generators,
+decorators, threading, power features, modern Python, type annotations, style
+rules, documentation, naming, main guards, and consistency.
+
+## Tool ownership
+
+| Area | Primary check | Interpretation |
+| --- | --- | --- |
+| Ruff lint rules | `pymake lint` | Report configured Ruff findings. |
+| Formatting | `pymake format dry_run=true` | Report formatter failures; do not auto-fix. |
+| Type correctness | `pymake check_types` | Report type-checker failures separately from style. |
+| Syntax and lexical bans | `scripts/check_google_rules.py` | Report confirmed findings. |
+| Documentation and design | Agent judgment plus supplemental checker | Inspect every public and private documentable symbol, including summary, `Args`, `Returns`/`Yields`, and `Raises` sections. |
+
+## Important local policy
+
+The guide's Pylint instructions are not executable requirements here. Ruff is
+the repository's lint and formatting tool, and `pymake` is the required task
+wrapper. Never install or run Pylint to satisfy this audit.
+
+The repository's Ruff configuration intentionally ignores some upstream rules,
+including line length and certain docstring rules. The agent must therefore
+review those Google-style requirements independently rather than treating a
+passing Ruff run as proof of compliance.
+
+## Hard versus judgment findings
+
+Treat syntax errors, relative imports, wildcard imports, semicolons, explicit
+line continuations, disallowed type comments, and `typing.Text` as
+deterministic candidates. Treat broad exceptions, assertions, mutable globals,
+long lines, long functions, nested definitions, and legacy typing aliases as
+review items unless repository context proves a direct violation. Missing or
+incomplete documentation for documentable public or private symbols is a
+strict audit finding under this skill's project policy. Verify a complete
+first-line summary, `Args:` for meaningful parameters, `Returns:` for returned
+values, `Yields:` for generators, and `Raises:` when exceptions are part of the
+contract.
+
+## Scope
+
+Exclude `node_modules`, `.venv`, caches, build output, vendored code, generated
+sources, and `.agents` by default. Include tests by default. Record exclusions
+and accepted exceptions in the audit report.