prettyplay 0.0.0__tar.gz

prettyplay-0.0.0/.github/workflows/docs.yml

@@ -0,0 +1,27 @@
+name: Release docs
+on:
+  push:
+    branches:
+      - 0.0.x
+
+permissions:
+  contents: write
+
+jobs:
+  deploy:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Configure Python
+        uses: actions/setup-python@v5
+        with:
+          python-version: 3.x
+
+      - name: Install dependencies
+        run: |
+          pip install -e ".[docs]"
+
+      - name: Build and Deploy
+        # gh-deploy creates the gh-pages branch and pushes static content there
+        run: mkdocs gh-deploy --force

prettyplay-0.0.0/.github/workflows/lint.yml

@@ -0,0 +1,20 @@
+name: Lint
+
+on:
+  push:
+    branches:
+      - 0.0.x
+  pull_request:
+    branches:
+      - 0.0.x
+
+jobs:
+  ruff:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: astral-sh/ruff-action@v3
+
+      - name: Check formatting
+        run: ruff format --check prettyplay/ tests/

prettyplay-0.0.0/.github/workflows/new_version.yml

@@ -0,0 +1,21 @@
+name: Open New Version
+
+on:
+  workflow_dispatch:
+    inputs:
+      type:
+        description: "New version type"
+        required: true
+        type: choice
+        options: [minor, major]
+
+permissions:
+  contents: write
+
+jobs:
+  create-branch:
+    uses: qarium/ci/.github/workflows/library-new-version.yml@0.0.x
+    with:
+      type: ${{ inputs.type }}
+    secrets:
+      GH_TOKEN: ${{ secrets.GH_TOKEN }}

prettyplay-0.0.0/.github/workflows/notify.yml

@@ -0,0 +1,17 @@
+name: Notify Release
+
+on:
+  workflow_run:
+    workflows: ["Publish Release"]
+    types: [completed]
+
+permissions:
+  contents: read
+
+jobs:
+  notify:
+    if: ${{ github.event.workflow_run.conclusion == 'success' }}
+    uses: qarium/ci/.github/workflows/library-notify.yml@0.0.x
+    secrets:
+      TELEGRAM_TOKEN: ${{ secrets.TELEGRAM_TOKEN }}
+      TELEGRAM_CHAT_ID: ${{ secrets.TELEGRAM_CHAT_ID }}

prettyplay-0.0.0/.github/workflows/publish.yml

@@ -0,0 +1,17 @@
+name: Publish Release
+
+on:
+  workflow_dispatch:
+
+permissions:
+  contents: write
+  id-token: write
+
+jobs:
+  release:
+    uses: qarium/ci/.github/workflows/library-publish.yml@0.0.x
+    with:
+      src-package: prettyplay
+    secrets:
+      PYPI_API_TOKEN: ${{ secrets.PYPI_API_TOKEN }}
+      ZAI_TOKEN: ${{ secrets.ZAI_TOKEN }}

prettyplay-0.0.0/.github/workflows/strictacode.yml

@@ -0,0 +1,43 @@
+name: Strictacode
+
+on:
+  push:
+    branches:
+      - '[0-9]+.[0-9]+.x'
+  pull_request:
+    branches:
+      - '[0-9]+.[0-9]+.x'
+
+jobs:
+  analyze:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.13"
+
+      - uses: actions/cache@v4
+        with:
+          path: ~/.cache/pip
+          key: ${{ runner.os }}-pip-${{ hashFiles('**/pyproject.toml') }}
+          restore-keys: |
+            ${{ runner.os }}-pip-
+
+      - uses: qarium/strictacode/.github/actions/analyze@0.0.x
+        with:
+          install-cmd: pip install strictacode
+          working-directory: prettyplay
+        env:
+          STRICTACODE_SCORE: 30
+          STRICTACODE_RP: 40
+          STRICTACODE_OP: 40
+          STRICTACODE_IMB: 15
+          STRICTACODE_DENSITY: 20
+          STRICTACODE_RP_DIFF: 5
+          STRICTACODE_OP_DIFF: 5
+          STRICTACODE_DENSITY_DIFF: 5
+          STRICTACODE_SCORE_DIFF: 3

prettyplay-0.0.0/.github/workflows/tests.yml

@@ -0,0 +1,14 @@
+name: Tests
+on:
+  push:
+    branches:
+      - '[0-9]+.[0-9]+.x'
+  pull_request:
+    branches:
+      - '[0-9]+.[0-9]+.x'
+
+jobs:
+  test:
+    uses: qarium/ci/.github/workflows/library-tests.yml@0.0.x
+    with:
+      python-versions: '["3.10", "3.11", "3.12", "3.13", "3.14"]'

prettyplay-0.0.0/.gitignore

@@ -0,0 +1,232 @@
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[codz]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+/build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+/MANIFEST
+
+# PyInstaller
+#  Usually these files are written by a python script from a template
+#  before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py.cover
+*,cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+.pybuilder/
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+#   For a library or package, you might want to ignore these files since the code is
+#   intended to run in multiple environments; otherwise, check them in:
+# .python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+#Pipfile.lock
+
+# UV
+#   Similar to Pipfile.lock, it is generally recommended to include uv.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#uv.lock
+
+# poetry
+#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
+#poetry.lock
+#poetry.toml
+
+# pdm
+#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
+#   pdm recommends including project-wide configuration in pdm.toml, but excluding .pdm-python.
+#   https://pdm-project.org/en/latest/usage/project/#working-with-version-control
+#pdm.lock
+#pdm.toml
+.pdm-python
+.pdm-build/
+
+# pixi
+#   Similar to Pipfile.lock, it is generally recommended to include pixi.lock in version control.
+#pixi.lock
+#   Pixi creates a virtual environment in the .pixi directory, just like venv module creates one
+#   in the .venv directory. It is recommended not to include this directory in version control.
+.pixi
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.envrc
+.venv*
+.docker-env
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+
+# pytype static type analyzer
+.pytype/
+
+# Cython debug symbols
+cython_debug/
+
+# PyCharm
+#  JetBrains specific template is maintained in a separate JetBrains.gitignore that can
+#  be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
+#  and can be added to the global gitignore or merged into this file.  For a more nuclear
+#  option (not recommended) you can uncomment the following to ignore the entire idea folder.
+#.idea/
+
+# Abstra
+# Abstra is an AI-powered process automation framework.
+# Ignore directories containing user credentials, local state, and settings.
+# Learn more at https://abstra.io/docs
+.abstra/
+
+# Visual Studio Code
+#  Visual Studio Code specific template is maintained in a separate VisualStudioCode.gitignore
+#  that can be found at https://github.com/github/gitignore/blob/main/Global/VisualStudioCode.gitignore
+#  and can be added to the global gitignore or merged into this file. However, if you prefer,
+#  you could uncomment the following to ignore the entire vscode folder
+# .vscode/
+
+# Ruff stuff:
+.ruff_cache/
+
+# PyPI configuration file
+.pypirc
+
+# Cursor
+#  Cursor is an AI-powered code editor. `.cursorignore` specifies files/directories to
+#  exclude from AI features like autocomplete and code analysis. Recommended for sensitive data
+#  refer to https://docs.cursor.com/context/ignore-files
+.cursorignore
+.cursorindexingignore
+
+# Marimo
+marimo/_static/
+marimo/_lsp/
+__marimo__/
+
+# IDE
+.idea/
+
+# AI
+.claude/
+.ralphex/
+docs/plans/
+docs/design/
+docs/arch/
+docs/tasks/
+docs/proposals/
+docs/superpowers/
+
+# Prettyplay step cache
+.prettyplay/
+
+# examole
+example.py
+
+# Agents
+.claude/
+CLAUDE.md

prettyplay-0.0.0/.goga/Dockerfile

@@ -0,0 +1,15 @@
+FROM qarium/goga-python-3.14:1.3
+
+USER root
+
+COPY agents/architector.sh /home/goga/bin/architector-as-claude.sh
+COPY agents/developer.sh /home/goga/bin/developer-as-claude.sh
+COPY agents/reviewer.sh /home/goga/bin/reviewer-as-claude.sh
+COPY agents/product.sh /home/goga/bin/product-as-claude.sh
+COPY agents/manager.sh /home/goga/bin/manager-as-claude.sh
+COPY agents/analyst.sh /home/goga/bin/analyst-as-claude.sh
+COPY agents/tester.sh /home/goga/bin/tester-as-claude.sh
+
+RUN chmod +x /home/goga/bin/*.sh
+
+USER goga

prettyplay-0.0.0/.goga/config.yml

@@ -0,0 +1,27 @@
+language: python
+
+image: prettyplay:latest
+dockerfile: .goga/Dockerfile
+
+.claude-env: &claude-env
+  ANTHROPIC_MODEL: opus
+  ANTHROPIC_BASE_URL: "https://api.z.ai/api/anthropic"
+
+build:
+  task_executor:
+    agent: developer
+  review_executor:
+    agent: reviewer
+    base_ref: master
+
+pipeline:
+  agent: claude
+  env:
+    <<: *claude-env
+    ANTHROPIC_DEFAULT_OPUS_MODEL: "glm-5.3[1m]"
+
+codemanifest:
+  usages:
+    conventions: .goga/usages/conventions.md
+  annotations: |
+    Use `conventions` for code writing rules and testing.

prettyplay-0.0.0/.goga/history/2026/additional-configuration/adr.md

@@ -0,0 +1,60 @@
+# Prettyplay Configuration Extension Decisions (branch `additional-configuration`)
+
+> Recorded from the technical discovery interview of 09.09.2026. Status: **approved**.
+> The topic was initiated by three user wishes formulated in the file-based dialog (no PRD/TODO was created for the topic). Facts about the current architecture were collected from `goga schema` and the CODEMANIFESTs of the config, driver, engine, cache cells. Each entry records the fact of the decision and its "why".
+
+## Terms
+
+- **Per-test runtime** — a runtime (a configuration instance, a browser process, an LLM provider, attempt budgets) owned by one `PrettyTest`, not by the whole process.
+- **PrettyConfig** — the public name of prettyplay's single full settings model (an alias of the config cell's `Config`); passed into `PrettyTest` for per-test overrides.
+- **Layered merging** — the rule for resolving a test's settings: a value explicitly set in `PrettyConfig` wins; an unset/empty one falls back to pyproject+env.
+- **Generation user instructions** — a `generation_prompt` settings string that lands in generation and regeneration requests as a separate USER INSTRUCTIONS block; it governs the style of the generated code (user's example: "prefer data-test-id attributes"), not failure diagnostics.
+- **`browser_endpoint`** — the ws endpoint address of a remote browser; an empty value means local launch, as today.
+
+---
+
+## ADR-1. Per-test runtime: every test gets its own browser and its own configuration
+
+Every `PrettyTest` builds its own runtime: its own configuration instance, its own browser process, its own provider, its own attempt budgets. The process-wide singleton is gone; `get_runtime()` leaves the public contract (an internal facade detail). Attempt budgets become per-test — the documented invariant "budgets are not reset between tests" is reversed. The user's choice: test isolation matters more than the economy of one browser per launch — "every test gets its own runtime, its own configuration instance and its own browser instance".
+
+**Alternatives considered:** keying runtimes by effective config (tests with an identical config share one browser) — rejected by the user: the runtime belongs to the test, not the config; a private runtime only when a config is explicitly passed — rejected: two behavior semantics in one library.
+
+**Consequences:** launching a browser per test (~a second) is the accepted price; a step reused by N tests gets N× attempts per launch — protection from infinite retries is preserved within each test; every runtime registers its own shutdown in atexit — all browsers stop by process exit; laziness is preserved — constructing `PrettyTest` is cheap, the browser starts on the first step.
+
+## ADR-2. PrettyConfig — a single settings model and layered merging
+
+`PrettyConfig` is the public name of the same full settings model (an alias of `Config`), not a separate lightweight override object. A config passed into `PrettyTest` sets only explicitly given values; unset/empty fields are resolved by layered merging against pyproject+env. One model — one place of validation and one resolution chain; "to pass a config" intuitively means "to override the specific", whereas with full replacement the `base_url`/`model` set in pyproject would be silently lost.
+
+**Alternatives considered:** a separate subset object for per-test overrides — rejected: divergence of two settings models; full replacement without merging — rejected: silent loss of file settings.
+
+**Consequences:** every new setting is automatically available along the whole pyproject → env → `PrettyConfig` chain; value validation is uniform for file-based and programmatic settings.
+
+## ADR-3. The `generation_prompt` setting — user instructions into generation requests
+
+A string setting `generation_prompt` appears (env `PRETTYPLAY_GENERATION_PROMPT`, default empty). A non-empty value lands as a separate **USER INSTRUCTIONS** block in generation and regeneration (healing) requests; the fixed system prompt does not change; failure classification is untouched (the instructions are about code style, classification is about diagnostics). The instructions are **not part of** the cache address: the cache is a repository of verified code — a working cached step is not regenerated because the style changed — the user's choice.
+
+**Alternatives considered:** pasting the instructions into the system prompt — rejected: the system prompt is a stable product, the instructions are variable request data; including an instructions hash in the step address — rejected by the user: changing the instructions must not invalidate the cache; extending to classification — rejected.
+
+**Consequences:** a change of instructions is visible only on fresh generation — cached steps stay as they are until a manual cache cleanup or regeneration by healing; the engine's internal usage named `generation_prompt` (the fixed system prompt) is renamed to `system_prompt`, freeing the term for the public setting — otherwise one name would be doing two jobs within one manifest.
+
+## ADR-4. Facade: universal locators — data attributes, CSS, XPath
+
+The page facade is extended with the ability to locate by any data attributes, CSS selectors and XPath. The system prompt's default priority (role → text → label) does not change — accessibility remains the global default, the priority is tuned per-project by user instructions. The topic's flagship scenario ("prefer data-test-id") requires the generated code to *be able* to search by test-id: the code works only through the facade, instructions alone without extending the surface are insufficient.
+
+**Alternatives considered:** changing the prompt's default priority to test-id-first — rejected: the global default is conservative, the priority is a project decision; limiting to instructions without extending the facade — rejected: the example is unfulfillable.
+
+**Consequences:** the backward-compatibility contract is honored — extend only, no renames or removals; the API surface is sent into requests from the facade usage, the model will see the new locators automatically (the listing and the usage change together).
+
+## ADR-5. Remote execution via the Playwright ws endpoint
+
+A string setting `browser_endpoint` appears (env `PRETTYPLAY_BROWSER_ENDPOINT`, default empty = local launch, as today). The mechanism is the Playwright ws endpoint (connect). An endpoint is set → the driver **connects** instead of launching locally; `headless` is ignored (window visibility is controlled by the server); `browser` still selects the engine type to connect to. An endpoint URL in the config is acceptable — it is an address, not a key; rotation in CI — via the env override (the user's remark "don't forget env" is covered by the general rule "every setting has an env override").
+
+**Alternatives considered:** CDP connection (`connect_over_cdp` to a running Chrome with a debugging port) — deferred as a future extension via a separate field; both mechanisms at once — rejected: extra surface before a real need.
+
+**Consequences:** the playwright usage (`.goga/usages/cooks/playwright.md`) gains a section on remote connection — remote is not described there today; combined with ADR-1, every test can connect to its own endpoint.
+
+---
+
+## Interview summary
+
+Three user wishes → solutions: a config in `PrettyTest` → ADR-1 + ADR-2; user input into the generation prompt → ADR-3 + ADR-4 (the data-test-id example pulled the facade extension along); playwright to remote execution → ADR-5. All decisions were approved by the user in the file-based dialog (questions q1–q5 in the pipeline stage directory): q1 — task formulation, q2 — a round of 10 frontier questions, q3 — a round of 6 (consequences of the per-test runtime), q4–q5 — the `generation_prompt` term collision and final confirmation. Contract design (signatures, CODEMANIFEST changes) — outside discovery scope.