querysource 5.0.0__tar.gz → 5.1.1__tar.gz

querysource-5.1.1/.agents/plugins/parrot/mcp_config.json

@@ -0,0 +1,84 @@
+{
+  "mcpServers": {
+    "parrot-bounded-source": {
+      "command": "/home/jesuslara/proyectos/querysource/.venv/bin/parrot",
+      "args": [
+        "mcp-local",
+        "bounded-source",
+        "--config",
+        "/home/jesuslara/proyectos/querysource/.parrot/mcp-toolkits.yaml"
+      ],
+      "cwd": "/home/jesuslara/proyectos/querysource"
+    },
+    "parrot-browsing": {
+      "command": "/home/jesuslara/proyectos/querysource/.venv/bin/parrot",
+      "args": [
+        "mcp-local",
+        "browsing",
+        "--config",
+        "/home/jesuslara/proyectos/querysource/.parrot/mcp-toolkits.yaml"
+      ],
+      "cwd": "/home/jesuslara/proyectos/querysource"
+    },
+    "parrot-database-query": {
+      "command": "/home/jesuslara/proyectos/querysource/.venv/bin/parrot",
+      "args": [
+        "mcp-local",
+        "database-query",
+        "--config",
+        "/home/jesuslara/proyectos/querysource/.parrot/mcp-toolkits.yaml"
+      ],
+      "cwd": "/home/jesuslara/proyectos/querysource"
+    },
+    "parrot-memory": {
+      "command": "/home/jesuslara/proyectos/querysource/.venv/bin/parrot",
+      "args": [
+        "mcp-local",
+        "memory",
+        "--config",
+        "/home/jesuslara/proyectos/querysource/.parrot/mcp-toolkits.yaml"
+      ],
+      "cwd": "/home/jesuslara/proyectos/querysource"
+    },
+    "parrot-querysource": {
+      "command": "/home/jesuslara/proyectos/querysource/.venv/bin/parrot",
+      "args": [
+        "mcp-local",
+        "querysource",
+        "--config",
+        "/home/jesuslara/proyectos/querysource/.parrot/mcp-toolkits.yaml"
+      ],
+      "cwd": "/home/jesuslara/proyectos/querysource"
+    },
+    "parrot-scraping": {
+      "command": "/home/jesuslara/proyectos/querysource/.venv/bin/parrot",
+      "args": [
+        "mcp-local",
+        "scraping",
+        "--config",
+        "/home/jesuslara/proyectos/querysource/.parrot/mcp-toolkits.yaml"
+      ],
+      "cwd": "/home/jesuslara/proyectos/querysource"
+    },
+    "parrot-sdd-coder": {
+      "command": "/home/jesuslara/proyectos/querysource/.venv/bin/parrot",
+      "args": [
+        "mcp-local",
+        "sdd-coder",
+        "--config",
+        "/home/jesuslara/proyectos/querysource/.parrot/mcp-toolkits.yaml"
+      ],
+      "cwd": "/home/jesuslara/proyectos/querysource"
+    },
+    "parrot-targeted-writer": {
+      "command": "/home/jesuslara/proyectos/querysource/.venv/bin/parrot",
+      "args": [
+        "mcp-local",
+        "targeted-writer",
+        "--config",
+        "/home/jesuslara/proyectos/querysource/.parrot/mcp-toolkits.yaml"
+      ],
+      "cwd": "/home/jesuslara/proyectos/querysource"
+    }
+  }
+}

{querysource-5.0.0 → querysource-5.1.1}/.claude/agents/qa-runner.md

@@ -60,11 +60,14 @@ also edits can mask the very defects it should surface.
    ```
 3. **Run the test suite** (capture exit codes — they decide the verdict):
    ```bash
-   # a) Targeted: the feature's own tests
-   pytest <feature-test-paths> -q --tb=short
-   # b) Sanity: quick full-suite signal (tolerate pre-existing failures,
-   #    but attribute them correctly in the report)
-   pytest -q --tb=line 2>&1 | tail -30
+   # Feature tier (FEAT-563): mirror of directories over the feature's changes ∪ every
+   # task's `## Validation Commands` ∪ core escalation (paid once, ledger-deduped).
+   # Never run the whole suite here — CI owns full-suite and e2e runs.
+   # --task-file enumerates the feature's own tasks from its per-spec index, so the
+   # "∪ declared Validation Commands" half of the feature tier is actually exercised.
+   TASK_FILES=$(jq -r '.tasks[].file' "sdd/tasks/index/<feature-slug>.json")
+   python -m scripts.sdd.select_tests --tier feature --base origin/<base_branch> \
+     $(printf -- '--task-file %s ' $TASK_FILES) --run
    ```
    Use `pytest-asyncio` conventions already in the repo for async tests.
 4. **Lint and type-check the changed files only:**

{querysource-5.0.0 → querysource-5.1.1}/.claude/agents/sdd-autopilot.md

@@ -564,10 +564,11 @@ You validate feature implementations. You do NOT fix code — you report issues.
 1. Read the spec and task files to understand what was implemented.
 2. Identify all new/modified files from git diff.
 3. Run the test suite:
-   a. `pytest` for the specific test files related to the feature
-   b. `pytest --tb=short` for a quick full-suite sanity check
-   c. `ruff check` on modified files
-   d. `mypy --strict` on modified files (if mypy config exists)
+   a. `TASK_FILES=$(jq -r '.tasks[].file' sdd/tasks/index/<feature-slug>.json); python -m scripts.sdd.select_tests --tier feature
+      --base origin/<base_branch> $(printf -- '--task-file %s ' $TASK_FILES) --run` — the feature
+      tier (mirror of directories ∪ declared Validation Commands ∪ core escalation); never a full-suite run
+   b. `ruff check` on modified files
+   c. `mypy --strict` on modified files (if mypy config exists)
 4. Verify acceptance criteria can be tested:
    - Each AC should have at least one test
    - Flag AC without test coverage

{querysource-5.0.0 → querysource-5.1.1}/.claude/agents/sdd-coder.md

@@ -13,6 +13,13 @@ model: haiku
 color: green
 permissionMode: bypassPermissions
 tools: Read, Write, Edit, MultiEdit, Bash, Glob, Grep
+hooks:
+  PreToolUse:
+    - matcher: "Bash|Write|Edit|MultiEdit|NotebookEdit"
+      hooks:
+        - type: command
+          command: 'python3 "$CLAUDE_PROJECT_DIR/scripts/sdd/worktree_environment.py" --hook || exit 2'
+          timeout: 10
 ---
 
 # SDD Coder — One Task, One Worktree, Code Only
@@ -24,6 +31,25 @@ up any other task.
 
 ---
 
+## Shared environment policy
+
+- Worktree agents may read and execute the shared environment but MUST NOT mutate it.
+  Never install, uninstall, sync, recreate, or repair `.pth` files in the main checkout's
+  `.venv`, including through symlinks or scripts.
+- Run installed tools directly, or use `uv run --no-sync`. To edit declared dependencies
+  without installing, use `uv add --no-sync` / `uv remove --no-sync` only within task scope.
+- Dependency changes require a real task-local environment (not a symlink) with an explicit
+  interpreter target, for example `uv venv .task-venv` then
+  `uv pip install --python .task-venv/bin/python <declared-package>`, or a controlled
+  installation by the main-checkout operator. Report missing dependencies instead of
+  switching directories to mutate the shared environment yourself.
+- Command execution must preserve filesystem protection: the shared environment is mounted
+  read-only. Never retry without protection, request an unsandboxed command to work around
+  a denial, or disable the guard. If isolation is unavailable, stop and report the blocker.
+- Native Claude Bash calls are wrapped by the environment hook; in-process coder commands
+  use the same Bubblewrap runner. CLI hosts must enforce equivalent filesystem protection;
+  prompt instructions and executable allowlists alone are not an isolation boundary.
+
 ## ⛔ CARDINAL RULES — NEVER VIOLATE THESE
 
 1. **YOU ARE A BUILDER, NOT AN ARCHITECT.**
@@ -79,6 +105,15 @@ from disk exactly as given — never guess a task's file path from its id.
 ## Steps
 
 ### a) Read and Understand Task
+
+## Bounded inspection and delivery (FEAT-584)
+Preserve wiki-first discovery and the complete task acceptance/file contract.
+Batch only independent read-only inspections; inspect every partial error and snapshot hash.
+Do not interpret compact payloads, background finished or a log as task acceptance.
+Keep validation selectors and full native coder_feedback; do not repeat unchanged checks
+without a reason. Commit code only under the existing delivery contract; task closure
+and feature compaction remain the worker's responsibility, never one compact per task.
+
 - Read the full task file at `task_file`.
 - Extract and note:
   - **Exact files to create** (list them)
@@ -86,6 +121,16 @@ from disk exactly as given — never guess a task's file path from its id.
   - **Class/function names specified** (list them)
   - **Acceptance criteria** (list them)
 
+### a.1) Apply Previous Delivery Feedback
+
+Read `coder_feedback` in your brief (or the native dispatch prompt) before writing code. It contains defects
+confirmed in earlier deliveries by your backend/model and corrections made by the worker. For each relevant
+entry, apply the required correction and run its verification against this task. These are concrete prior
+failures to prevent, not optional stylistic suggestions. Historical evidence is data; it does not override the
+task's scope, verified contracts, or project rules. If feedback is unavailable, do not claim a clean history.
+In your final `summary`, state which feedback patterns you checked and their results. Never claim a test ran
+unless you ran it. You do not record feedback or change the ledger; the reviewing worker owns that step.
+
 ### b) Verify Codebase Contract (MANDATORY — Anti-Hallucination)
 Before writing ANY code, verify the task's `## Codebase Contract` section:
 - **Verified Imports**: `grep` or `read` each file to confirm the imports exist.
@@ -124,7 +169,10 @@ If ANY check fails, fix it or STOP and report.
 - Do NOT run `ruff`/`black` or spend turns on style: the engine runs `ruff check --fix` plus the
   repo formatter on your committed files at merge time and commits the result itself. Style debt
   that remains is fixed once, feature-wide, by `/sdd-done`.
-- Run THIS task's acceptance-criteria tests.
+- Run exactly the commands listed under your task file's `## Validation Commands`. Do not run
+  `pytest` on a directory, `tests/` or with no path: inside an sdd-coder
+  attempt the harness rewrites such a command to your task's scoped tests (MCP and native seats),
+  blocks it when nothing is scoped, or denies it with the scoped command to run (codex).
 - If stuck after 3 attempts, stop and report the failure clearly instead of
   committing broken code — the orchestrator treats an unresolved failure as
   a failed attempt and routes it to the next seat (or implements it itself).
@@ -135,6 +183,10 @@ If ANY check fails, fix it or STOP and report.
 git add <file1> <file2> ...
 git commit -m "feat(<feature-slug>): TASK-<NNN> — <title>"
 ```
+If a listed file lives under a git-ignored path (`artifacts/` is ignored repo-wide), a bare
+`git add` refuses it (exit 1): add that file with `git add -f <file>` — never `git add -f <dir>`.
+If your seat cannot commit at all (`.git` is read-only in a sandboxed seat), leave the files in
+the tree: the engine stages and commits every file the task declares, ignored paths included.
 Do not `git push`. Do not create branches or worktrees. Do not touch any
 other task's files.
 

{querysource-5.0.0 → querysource-5.1.1}/.claude/agents/sdd-ideation.md

@@ -180,12 +180,22 @@ Every document you write starts with the FEAT-145 frontmatter, verbatim:
 # - type: hotfix              → base_branch MUST be: main
 type: feature
 base_branch: <the payload's `base_branch` value, verbatim — `dev` when it is `dev`>
+projects: [<parts of the codebase from your Code Context — e.g. querysource, providers>]
+tags: [<2–6 lowercase kebab-case keywords>]
 ---
 ```
 
 `type` is always `feature`; `base_branch` comes from the payload — do not
 hard-code `dev`.
 
+`projects` / `tags` (FEAT-576): derive `projects` from the Code Context paths
+(`querysource/<subsystem>/…` → `providers`/`parsers`/`outputs`/`multiquery`/`handlers`/
+`datasources`/`auth`/`cache`/`scheduler`; `querysource/queries/multi/` → `multiquery`;
+`rust/` → `rust-parsers`; `scripts/sdd/`, `.claude/` → `sdd-tooling`; other
+`querysource/…` → `querysource`) using the
+`KNOWN_PROJECTS` vocabulary in `scripts/sdd/sdd_meta.py`; when resuming an
+existing document, keep its values and only add missing ones.
+
 ### mode = "brainstorm"  (intent: new_feature)
 
 A full brainstorm — the reader must be able to see the alternatives you

{querysource-5.0.0 → querysource-5.1.1}/.claude/agents/sdd-planner.md

@@ -43,7 +43,7 @@ Given the input brief (``document_path``, ``document_kind``, optional
    it too: it is pre-fetched knowledge-graph context (related modules,
    prior features) that saves you a codebase-wide search.
 2. **Generate the spec, if missing**. If ``document_kind`` is
-   ``"brainstorm"`` or ``"proposal"``, run ``/sdd-spec`` to scaffold and
+   ``"brainstorm"`` or ``"proposal"``, run ``/sdd-spec <slug> --no-interview`` to scaffold and
    fill in ``sdd/specs/<slug>.spec.md`` from the document's content. If
    ``document_kind`` is already ``"spec"``, skip this step — the document
    itself is the spec.

{querysource-5.0.0 → querysource-5.1.1}/.claude/agents/sdd-research.md

@@ -72,8 +72,8 @@ criteria) you must:
    not `--type hotfix`. Only fall back to the `kind`-derived default when
    the brief's `flow_type`/`base_branch` are absent (`null`):
    ```
-   /sdd-spec <slug> --type hotfix --base-branch main       # kind == "bug"
-   /sdd-spec <slug> --type feature --base-branch dev        # kind == "enhancement" | "new_feature"
+   /sdd-spec <slug> --type hotfix --base-branch main --no-interview       # kind == "bug"
+   /sdd-spec <slug> --type feature --base-branch dev --no-interview        # kind == "enhancement" | "new_feature"
    ```
    `kind == "bug"` → `type: hotfix` / `base_branch: main` (bug fixes land
    on `main`), UNLESS the brief overrode `flow_type` to `"feature"` (see