pythia-plsql 0.8.0__tar.gz → 0.10.0__tar.gz

{pythia_plsql-0.8.0/scripts/pythia_plsql.egg-info → pythia_plsql-0.10.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: pythia-plsql
-Version: 0.8.0
+Version: 0.10.0
 Summary: PL/SQL development for AI agents on Oracle Database - expert data-dictionary queries, impact analysis, and a snapshot-verified write path with honest rollback.
 License: MIT
 Project-URL: Homepage, https://github.com/thaildhe172591/pythia
@@ -101,11 +101,14 @@ through one door: **snapshot → impact → preview → token → approve → ap
 verify → report**. DDL self-commits in Oracle, so the snapshot is the only real
 undo — it runs first and no flag disables it. A content-bound token guarantees
 what lands is byte-for-byte what was previewed, and a **developer-minted grant**
-guarantees a person approved it at all: `pythia approve` runs only at a human's
-own console, and without its one-time grant `apply --confirm` refuses. The
-agent's command line is unchanged; what changed is that it now stops until
-someone acts. A headless agent cannot `--yes` its own writes, cannot approve
-them, and cannot loosen policy — each of those takes a human at a real terminal.
+guarantees a person approved it at all — through one of two doors, both the
+developer's. In chat: the agent asks with `AskUserQuestion`, the question text
+being pythia's own approval card (`pythia approve --card <token>`), and the
+answer **Approve** — written into the hook payload by Claude Code, never by
+the agent — mints the one-time grant. At a console: `pythia approve <token>`.
+Without that grant `apply --confirm` refuses. A headless agent cannot `--yes`
+its own writes, cannot mint approval, and cannot loosen policy — each of those
+takes a human, answering or typing.
 
 The same discipline holds when the *developer* does the work: `src` and
 `impact` silently snapshot what they read, so even a change made by hand in
@@ -211,7 +214,7 @@ Per-group write policy, `.pythia/policy.json` (defaults shown):
 | Group | Default | Is rollback real? |
 |---|---|---|
 | `plsql_source` | `confirm` | **Yes — completely.** Source is recoverable from `ALL_SOURCE`. |
-| `data_dml` | `deny` | **No.** After commit only Flashback Query remains, within undo retention. |
+| `data_dml` | `deny` | **No.** After commit only Flashback Query remains, within undo retention. Revalidation checks the row set *before* the write; it is not an undo. |
 | `structural` | `deny` | **Almost never.** `DROP COLUMN` is permanent; a dropped table may be in the Recycle Bin. |
 | `grants` | `deny` | Yes, but by hand. |
 | `session` | `allow` | Not needed. |

{pythia_plsql-0.8.0 → pythia_plsql-0.10.0}/README.md

@@ -87,11 +87,14 @@ through one door: **snapshot → impact → preview → token → approve → ap
 verify → report**. DDL self-commits in Oracle, so the snapshot is the only real
 undo — it runs first and no flag disables it. A content-bound token guarantees
 what lands is byte-for-byte what was previewed, and a **developer-minted grant**
-guarantees a person approved it at all: `pythia approve` runs only at a human's
-own console, and without its one-time grant `apply --confirm` refuses. The
-agent's command line is unchanged; what changed is that it now stops until
-someone acts. A headless agent cannot `--yes` its own writes, cannot approve
-them, and cannot loosen policy — each of those takes a human at a real terminal.
+guarantees a person approved it at all — through one of two doors, both the
+developer's. In chat: the agent asks with `AskUserQuestion`, the question text
+being pythia's own approval card (`pythia approve --card <token>`), and the
+answer **Approve** — written into the hook payload by Claude Code, never by
+the agent — mints the one-time grant. At a console: `pythia approve <token>`.
+Without that grant `apply --confirm` refuses. A headless agent cannot `--yes`
+its own writes, cannot mint approval, and cannot loosen policy — each of those
+takes a human, answering or typing.
 
 The same discipline holds when the *developer* does the work: `src` and
 `impact` silently snapshot what they read, so even a change made by hand in
@@ -197,7 +200,7 @@ Per-group write policy, `.pythia/policy.json` (defaults shown):
 | Group | Default | Is rollback real? |
 |---|---|---|
 | `plsql_source` | `confirm` | **Yes — completely.** Source is recoverable from `ALL_SOURCE`. |
-| `data_dml` | `deny` | **No.** After commit only Flashback Query remains, within undo retention. |
+| `data_dml` | `deny` | **No.** After commit only Flashback Query remains, within undo retention. Revalidation checks the row set *before* the write; it is not an undo. |
 | `structural` | `deny` | **Almost never.** `DROP COLUMN` is permanent; a dropped table may be in the Recycle Bin. |
 | `grants` | `deny` | Yes, but by hand. |
 | `session` | `allow` | Not needed. |

{pythia_plsql-0.8.0 → pythia_plsql-0.10.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "pythia-plsql"
-version = "0.8.0"
+version = "0.10.0"
 description = "PL/SQL development for AI agents on Oracle Database - expert data-dictionary queries, impact analysis, and a snapshot-verified write path with honest rollback."
 readme = "README.md"
 license = { text = "MIT" }

pythia_plsql-0.10.0/queries/current-schema.sql

@@ -0,0 +1,6 @@
+-- Purpose: the schema an unqualified CREATE lands in for this session. A proxy
+--          or a mis-set connections.json can put it somewhere other than the
+--          schema pythia snapshots and verifies; apply refuses that mismatch.
+-- Binds:   none
+-- Returns: CURRENT_SCHEMA
+select sys_context('userenv', 'current_schema') current_schema from dual