sia-package 0.2.0__tar.gz

sia_package-0.2.0/AGENT.md

@@ -0,0 +1,141 @@
+# SIA (Self Improving Agents)
+
+## Runtime Re-entry
+
+When the `sia` CLI is installed, run `sia next --json` before SIA work and
+after a new session or context compaction. The persisted `.sia/state.json`
+stage is authoritative; this file supplies the detailed policy. Select
+`advisory`, `planning`, or `orchestrator` mode during `sia init`. SIA is
+explicitly invoked and must coexist with other skills/plugins according to
+`HOST-INTEGRATION.md`; do not install an always-on hook.
+
+## What This Is
+
+SIA is a portable, host-agnostic instruction package. It turns any coding
+assistant that can read files, load skill/instruction files, and spawn
+scoped subagents into a self-improving project collaborator — one that
+authors its own project-specific process artifacts instead of declaring
+"done" prematurely.
+
+**Read this file in full before taking any other action in this project.**
+
+SIA is a *generator*, not a library of pre-built domain packs. Every
+project gets its own fresh `AGENT.md`, spec, plan, **project-specific
+skill files**, and subagent task briefs, authored from that project's
+evidence — never copied from another project. The one exception is
+`guides/security-gate.md`, a fixed, reused checklist loaded only for
+software projects.
+
+**If you're setting SIA up in a project for the first time** (this file
+exists but nothing generated by it does yet), read `INSTALL.md` first —
+it covers gitignoring this vendored `sia/` folder correctly (keeping the
+*generated* artifacts committed) and, for Claude Code, an optional
+discovery shim so this file gets found without being told to.
+
+## Authority Order
+
+When two sources of instruction conflict, resolve in this order, highest
+first:
+
+1. **User instructions** — whatever the user says in the current
+   conversation, directly.
+2. **This project's own `AGENT.md`** — the generated file, including its
+   Project-Specific Rules and Accumulated Feedback Rules.
+3. **The approved spec/plan** for the current piece of work.
+4. **SIA's static guides** (this file and everything under `guides/`).
+5. **A subagent's own task brief** — the narrowest, most disposable
+   layer; a brief is written *from* the plan and guides above it, and
+   never overrides them.
+
+A guide describes the default; a project's own `AGENT.md` rule exists
+specifically to override a default that didn't fit that project (that is
+the entire point of the Accumulated Feedback Rules mechanism — see
+`capture-interface.md`). If a static guide and a project's own rule ever
+conflict, the project's rule wins, and the conflict itself is worth a
+Medium-severity note back to the user rather than silent resolution
+either way.
+
+## Guides
+
+Load these as needed, per the pipeline stage you're in:
+
+- `guides/questioning-and-approval.md` — batching clarifying questions,
+  severity-tagged approval gates. Applies to every stage.
+- `guides/writing-agent-md.md` — how to author *this project's own*
+  `AGENT.md`/`AGENTS.md`.
+- `guides/writing-spec.md` — how to author *this project's own* spec.
+- `guides/writing-plan.md` — how to break a spec into an implementation
+  plan.
+- `guides/writing-project-skills.md` — how to synthesize the project's
+  own host-discoverable skills from its goals, contract, and plan.
+- `guides/subagent-task-brief.md` — task brief / report / progress-log
+  formats for subagent-driven execution.
+- `guides/security-gate.md` — fixed threat-class checklist. Load only
+  when this project is a software project (greenfield or brownfield).
+
+See also `capture-interface.md` for the feedback-capture schema and the
+self-healing loop-engineering mechanism, and `VALIDATION.md` for how this
+package is dogfooded before a version is called stable.
+
+## Launch Screen
+
+If your host can run a shell command, run `python3 sia/banner.py` once at
+the start of a session in this project and show its output before
+proceeding — it prints the SIA mark and a one-line status of which gates
+are active (loop engineering, security gate, human approval gates). If your
+host cannot execute shell commands, read and display `sia/BANNER.txt`
+instead — the same banner, pre-rendered as plain text, with the directory
+line left as a `<current project directory>` placeholder for you to fill in
+or drop. Either way this is cosmetic — skip it entirely rather than block
+on it if neither option is available.
+
+## Pipeline
+
+1. **Bootstrap** — you're doing this now, by reading this file. Show the
+   launch screen above first, if your host supports it.
+2. **Intake** — look for an existing requirements artifact (`.md`,
+   `.pdf`, `.docx`, or similar) anywhere reasonable in the project. Form
+   a best guess of project type from what's present (existing code and
+   its stack → greenfield/brownfield software; `.pptx`/`.docx`/proposal
+   language → document/deck prep; design assets/mockup language →
+   design work). State the guess and your evidence, then ask the user
+   to confirm or correct it, batched into one question per
+   `guides/questioning-and-approval.md`. If no artifact exists,
+   interview the user instead, same batching rule.
+3. **Spec authoring** — using `guides/writing-spec.md`, write this
+   project's own spec into its own `docs/specs/`.
+4. **AGENT.md authoring** — using `guides/writing-agent-md.md`, write
+   this project's own `AGENT.md`/`AGENTS.md`.
+5. **Project-skill synthesis** — using
+   `guides/writing-project-skills.md`, generate the host-discoverable,
+   project-specific skills required for this project. Record their
+   provenance in a skill manifest. The user never has to design this
+   skill pack manually.
+6. **Plan authoring** — using `guides/writing-plan.md`, break the spec
+   into an implementation plan, saved into this project's own
+   `docs/plans/`.
+7. **Execution** — using `guides/subagent-task-brief.md`, materialize a
+   brief, host-dispatch record, subagent report, and reviewer verdict for
+   every implementation task. If the host can spawn subagents, the
+   controller **must not implement a task-owned file itself**: it briefs,
+   dispatches, reviews, integrates, and escalates. If the host cannot
+   spawn subagents, stop and tell the user before implementation rather
+   than silently substituting single-agent work. After every task in the
+   plan is individually reviewed and complete, run one **Integration
+   phase** before declaring the plan done: run the project's full
+   test/build suite (not just each task's own check), verify the named
+   Interfaces between tasks actually match up in the combined code (not
+   just each task's own diff in isolation), and review the whole plan's
+   combined diff as one unit.
+8. **Feedback loop** — capture corrections, review findings, and (for
+   software projects) security-gate findings via
+   `capture(signal_type, context, severity, error_class)` (see `capture-interface.md`),
+   fold them into this project's own `AGENT.md` as standing rules, and
+   run the pre-flight self-check from `capture-interface.md` before
+   presenting the next piece of work.
+
+Approval gates (`guides/questioning-and-approval.md`) wrap every stage.
+Never assume on a non-trivial decision; never delete, replace, or
+restructure anything without explicit approval; never declare a stage
+"done" until its acceptance criteria are met and the user has approved
+any high-impact work in it.

sia_package-0.2.0/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 GunjanGrunge
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

sia_package-0.2.0/PKG-INFO

@@ -0,0 +1,119 @@
+Metadata-Version: 2.2
+Name: sia-package
+Version: 0.2.0
+Summary: Host-neutral, persistent orchestration for Self-Improving Agents
+Author: GunjanGrunge
+License: MIT
+Project-URL: Homepage, https://github.com/GunjanGrunge/SIA_package
+Project-URL: Repository, https://github.com/GunjanGrunge/SIA_package
+Project-URL: Issues, https://github.com/GunjanGrunge/SIA_package/issues
+Requires-Python: >=3.10
+Description-Content-Type: text/markdown
+License-File: LICENSE
+
+<p align="center">
+  <img src="./assets/sia-banner.png" alt="SIA: Self-Improving Agents" width="100%" />
+</p>
+
+<p align="center">
+  <img src="https://img.shields.io/badge/version-0.2.0-00F2FE.svg?style=flat-square" alt="Version 0.2.0" />
+  <img src="https://img.shields.io/badge/status-active-success.svg?style=flat-square" alt="Status: Active" />
+  <img src="https://img.shields.io/badge/license-MIT-lightgrey.svg?style=flat-square" alt="License: MIT" />
+  <img src="https://img.shields.io/badge/host--agnostic-yes-7B2CBF.svg?style=flat-square" alt="Host-agnostic" />
+</p>
+
+<p align="center"><b>Persistent, host-neutral orchestration for self-improving coding agents.</b></p>
+
+SIA combines detailed workflow guidance with an installable Python CLI. The CLI
+keeps the current stage, subagent evidence, feedback events, standing rules,
+and convergence data under `.sia/`, so SIA survives fresh chats and context
+compaction instead of appearing only at the beginning of a session.
+
+SIA supports three explicit modes: `advisory`, `planning`, and `orchestrator`.
+Its host adapters are manual launchers, so BMAD, Superpowers, and other plugins
+remain usable in parallel.
+
+## Install
+
+```powershell
+python -m pip install sia-package
+sia init --mode orchestrator
+sia adapter install --host kiro
+sia next --json
+```
+
+Replace `kiro` with `claude`, `codex`, or `antigravity`. You can also vendor
+this repository as `sia/`; see [`INSTALL.md`](./INSTALL.md). No provider API
+key or cloud service is required by SIA itself.
+
+## Core commands
+
+```text
+sia init --mode advisory|planning|orchestrator
+sia next --json                  durable host re-entry packet
+sia advance --evidence <path>    evidence-gated stage transition
+sia task prepare ...             establish exclusive file ownership
+sia task dispatch ...            persist native host agent/run identity
+sia task finish ...              attach report + independently identified review
+sia integration --evidence ...   attach combined validation/review
+sia record ... / sia capture ... persist PASS/DEVIATION outcomes
+sia rule add ... / sia preflight ... / sia convergence
+sia adapter install --host ...   install an explicit, namespaced launcher
+sia owner --stage plan --to bmad assign stage ownership in bridge mode
+sia doctor                       diagnose project integration
+```
+
+The CLI does not fake universal agent spawning. Claude Code, Codex, Kiro, and
+Antigravity create agents through their own native harnesses; SIA checks the
+ordering, ownership, and completeness of the common brief/dispatch/review
+record. Native IDs are caller-attested because vendor harnesses do not expose
+one shared authentication API. See
+[`HOST-INTEGRATION.md`](./HOST-INTEGRATION.md).
+
+## Architecture
+
+<p align="center">
+  <img src="./assets/architecture-flowchart.png" alt="SIA pipeline diagram" width="100%" />
+</p>
+
+```text
+host /sia command
+       │
+       ▼
+sia next --json ──► .sia/config.json + .sia/state.json
+       │
+       ├── guidance: AGENT.md / installed `sia guide`
+       ├── native agents: host-owned spawning and parallelism
+       ├── evidence: .sia/runs/<run-id>/
+       └── learning: events.jsonl + rules.json + preflight/convergence
+```
+
+## Repository layout
+
+```text
+src/sia/                         # installable CLI and orchestration runtime
+AGENT.md                         # detailed vendored workflow policy
+HOST-INTEGRATION.md              # modes, adapters, and coexistence contract
+guides/                          # spec/plan/skill/task/security guidance
+integrations/                    # source shims for supported hosts
+capture-interface.md             # feedback and convergence semantics
+tests/validate_sia.py            # package contract validator
+```
+
+## Coexistence
+
+The default `bridge` policy detects common framework folders, records them in
+`.sia/config.json`, never replaces root `AGENT.md`/`AGENTS.md`, and refuses to
+overwrite adapter files. Choose `advisory` when another framework owns the
+whole development workflow, `planning` when it owns execution, or
+`orchestrator` when SIA should own native-agent dispatch and integration.
+
+## Validation
+
+Run `python tests/validate_sia.py`, `python -m compileall src`, and a CLI smoke
+run in a temporary project. `VALIDATION.md` contains host-level dogfood
+scenarios that cannot be proven by structural tests alone.
+
+## License
+
+MIT.

sia_package-0.2.0/README.md

@@ -0,0 +1,106 @@
+<p align="center">
+  <img src="./assets/sia-banner.png" alt="SIA: Self-Improving Agents" width="100%" />
+</p>
+
+<p align="center">
+  <img src="https://img.shields.io/badge/version-0.2.0-00F2FE.svg?style=flat-square" alt="Version 0.2.0" />
+  <img src="https://img.shields.io/badge/status-active-success.svg?style=flat-square" alt="Status: Active" />
+  <img src="https://img.shields.io/badge/license-MIT-lightgrey.svg?style=flat-square" alt="License: MIT" />
+  <img src="https://img.shields.io/badge/host--agnostic-yes-7B2CBF.svg?style=flat-square" alt="Host-agnostic" />
+</p>
+
+<p align="center"><b>Persistent, host-neutral orchestration for self-improving coding agents.</b></p>
+
+SIA combines detailed workflow guidance with an installable Python CLI. The CLI
+keeps the current stage, subagent evidence, feedback events, standing rules,
+and convergence data under `.sia/`, so SIA survives fresh chats and context
+compaction instead of appearing only at the beginning of a session.
+
+SIA supports three explicit modes: `advisory`, `planning`, and `orchestrator`.
+Its host adapters are manual launchers, so BMAD, Superpowers, and other plugins
+remain usable in parallel.
+
+## Install
+
+```powershell
+python -m pip install sia-package
+sia init --mode orchestrator
+sia adapter install --host kiro
+sia next --json
+```
+
+Replace `kiro` with `claude`, `codex`, or `antigravity`. You can also vendor
+this repository as `sia/`; see [`INSTALL.md`](./INSTALL.md). No provider API
+key or cloud service is required by SIA itself.
+
+## Core commands
+
+```text
+sia init --mode advisory|planning|orchestrator
+sia next --json                  durable host re-entry packet
+sia advance --evidence <path>    evidence-gated stage transition
+sia task prepare ...             establish exclusive file ownership
+sia task dispatch ...            persist native host agent/run identity
+sia task finish ...              attach report + independently identified review
+sia integration --evidence ...   attach combined validation/review
+sia record ... / sia capture ... persist PASS/DEVIATION outcomes
+sia rule add ... / sia preflight ... / sia convergence
+sia adapter install --host ...   install an explicit, namespaced launcher
+sia owner --stage plan --to bmad assign stage ownership in bridge mode
+sia doctor                       diagnose project integration
+```
+
+The CLI does not fake universal agent spawning. Claude Code, Codex, Kiro, and
+Antigravity create agents through their own native harnesses; SIA checks the
+ordering, ownership, and completeness of the common brief/dispatch/review
+record. Native IDs are caller-attested because vendor harnesses do not expose
+one shared authentication API. See
+[`HOST-INTEGRATION.md`](./HOST-INTEGRATION.md).
+
+## Architecture
+
+<p align="center">
+  <img src="./assets/architecture-flowchart.png" alt="SIA pipeline diagram" width="100%" />
+</p>
+
+```text
+host /sia command
+       │
+       ▼
+sia next --json ──► .sia/config.json + .sia/state.json
+       │
+       ├── guidance: AGENT.md / installed `sia guide`
+       ├── native agents: host-owned spawning and parallelism
+       ├── evidence: .sia/runs/<run-id>/
+       └── learning: events.jsonl + rules.json + preflight/convergence
+```
+
+## Repository layout
+
+```text
+src/sia/                         # installable CLI and orchestration runtime
+AGENT.md                         # detailed vendored workflow policy
+HOST-INTEGRATION.md              # modes, adapters, and coexistence contract
+guides/                          # spec/plan/skill/task/security guidance
+integrations/                    # source shims for supported hosts
+capture-interface.md             # feedback and convergence semantics
+tests/validate_sia.py            # package contract validator
+```
+
+## Coexistence
+
+The default `bridge` policy detects common framework folders, records them in
+`.sia/config.json`, never replaces root `AGENT.md`/`AGENTS.md`, and refuses to
+overwrite adapter files. Choose `advisory` when another framework owns the
+whole development workflow, `planning` when it owns execution, or
+`orchestrator` when SIA should own native-agent dispatch and integration.
+
+## Validation
+
+Run `python tests/validate_sia.py`, `python -m compileall src`, and a CLI smoke
+run in a temporary project. `VALIDATION.md` contains host-level dogfood
+scenarios that cannot be proven by structural tests alone.
+
+## License
+
+MIT.

sia_package-0.2.0/capture-interface.md

@@ -0,0 +1,166 @@
+# Feedback Capture Interface & Loop Engineering
+
+This is SIA's self-improving layer: how a project accumulates fewer
+mistakes over its own lifetime, not just a longer history of them.
+
+## The Interface
+
+```
+capture(signal_type, context, severity, error_class)
+```
+
+- `signal_type` — free-text category, project-defined (e.g.
+  `security-finding`, `user-correction`, `review-finding`,
+  `spec-ambiguity`).
+- `context` — what happened and where: a file/section reference, and
+  the user's correction verbatim where one exists.
+- `severity` — `low` / `medium` / `high`, the same scale as
+  `guides/questioning-and-approval.md`'s severity table.
+- `error_class` — a short, reusable label for *what kind* of mistake this
+  is, distinct from `signal_type` (which is about where the signal came
+  from). Reuse an existing class if this DEVIATION is the same kind of
+  mistake as one already captured; only mint a new class when it
+  genuinely isn't. Example classes: `unsafe-edit-target` (proposing to
+  change something that shouldn't be hand-edited, e.g. a generated
+  artifact), `missing-approval` (proceeding on a High-severity action
+  without confirmation), `interface-assumption` (assuming a type/shape
+  that turned out wrong), `unverified-claim` (asserting something works
+  without the evidence to back it — see Rule Provenance below for why
+  this class matters especially). This is what makes recurrence
+  trackable *by kind of mistake*, not just as one undifferentiated rate
+  (see Convergence Signal).
+
+Every call appends a structured entry to that project's session log.
+When the signal represents a standing rule ("don't delete components
+without asking", "always sanitize this auth flow"), propose adding it
+to that project's own `AGENT.md` under Accumulated Feedback Rules (see
+`guides/writing-agent-md.md`), subject to the normal approval gate for
+anything above low severity — recorded with the full provenance fields
+below, not just the rule text.
+
+## Rule Provenance
+
+Every Accumulated Feedback Rule carries, not just the rule text itself:
+
+- **Source event** — the specific session/experiment/task that produced
+  it (a session-log reference, not "learned over time").
+- **Evidence** — the actual `context` from the `capture()` call that
+  produced it, quoted, not paraphrased.
+- **Severity** — carried over from the originating `capture()` call.
+- **Error class** — carried over from the originating `capture()` call.
+- **Scope** — exactly what this rule governs (a file, a pattern, a
+  category of action) — narrow enough that a future pre-flight check can
+  actually tell whether a proposed change falls under it.
+- **Date introduced.**
+- **Status** — `active` or `retired` (see Rule Hygiene's expiry
+  mechanism below). A retired rule stays in the file with its status
+  changed, not deleted — deleting it would erase the provenance record
+  of why it existed at all.
+
+A rule missing any of these fields is incomplete — propose the complete
+record, not just the imperative sentence, when adding one.
+
+## PASS / DEVIATION
+
+Classify every stage outcome as one of:
+
+- **PASS** — the user approved without correction, verification/tests
+  passed, review found nothing.
+- **DEVIATION** — a user correction, a rejected proposal, a
+  security-gate finding, a failed verification, a review finding.
+
+Only DEVIATIONs are captured via the interface above. PASSes aren't
+logged for their own sake, but they feed the Convergence Signal below.
+
+### Process And Framework Deviations
+
+Capture process failures as seriously as code failures. Examples include
+skipping project-skill synthesis, a controller implementing a task that
+should have been delegated, a missing dispatch record, or claiming token
+budget compliance without host telemetry. Use a specific error class such
+as `framework-default-override`, record the evidence, and turn the
+correction into an active project rule before the next task.
+
+## Pre-Flight Self-Check
+
+Logging a DEVIATION is necessary but not sufficient — this step is what
+actually makes the loop self-healing rather than a history nobody
+re-reads. Before presenting the *next* proposal, spec section, plan, or
+generated change:
+
+1. Read that project's current `AGENT.md` Accumulated Feedback Rules
+   section in full.
+2. Check the work about to be presented against every rule there.
+3. Silently self-correct anything that would violate a low-severity
+   rule before showing the user anything.
+4. For anything that would violate a medium/high-severity rule, state
+   the conflict explicitly — e.g. "this would touch the auth flow
+   flagged after the correction on 2026-09-10; proceeding needs your
+   approval per that rule" — and route it through the approval gate.
+
+## Convergence Signal
+
+Compute a **deviation rate** (deviations ÷ total proposals) per
+milestone or per week of active work, from the session log's PASS/
+DEVIATION history — but compute it **per error class, not only as one
+overall number**. An overall rate can look flat or falling while one
+specific class of mistake (e.g. `unverified-claim`) keeps recurring
+underneath it, masked by other classes improving. Track each class's own
+count and trend.
+
+This is not a score to game — it's a trend to show the user
+periodically. A falling rate on a given class is evidence the rule
+governing that class is working. A flat or rising rate on the *same
+class* is itself worth raising directly with the user ("we've hit
+`interface-assumption` deviations three times — worth revisiting the
+spec instead of patching the code again?") rather than silently logging
+a fourth entry. A single self-administered test run (one evaluator
+writing both the rules and the test cases) will tend to show artificially
+low deviation rates across every class — the strongest version of this
+signal comes from real, independently-authored requests over real
+elapsed sessions, not a single sitting's worth of self-designed probes.
+
+## Rule Hygiene
+
+Accumulated rules must stay small enough to actually be re-read at every
+pre-flight check. When new rules overlap or supersede older ones,
+propose consolidating them (merge, generalize, or retire a rule the
+project has outgrown) rather than letting the list grow without bound.
+Consolidation is a medium-severity change — it goes through the normal
+approval gate, so the user always sees what's being merged or dropped
+and why.
+
+### Rule Review And Expiry
+
+Rules do not stay correct forever — a codebase changes underneath them.
+At a natural review point (a new plan's Spec-authoring stage is a good
+default trigger, since it already re-reads project context), check each
+`active` rule against current reality:
+
+- **Still applies, unchanged** — leave it.
+- **Superseded by a newer, more specific rule** — mark the old one
+  `retired`, with a one-line pointer to what replaced it. Do not delete
+  it (see Rule Provenance).
+- **No longer applies** (the code/constraint it was about was removed or
+  changed) — mark it `retired` with the reason, through the normal
+  approval gate (this is itself a medium-severity change — retiring a
+  rule silently is how a stale rule's *absence* becomes a surprise
+  later).
+- **Contradicts another active rule** — this is a Rule Hygiene failure
+  that should have been caught at consolidation time; surface it to the
+  user rather than silently picking a side.
+
+A project's Accumulated Feedback Rules section should therefore be read,
+in full, as "the currently active rules, plus a retired history below
+them" — not assumed to be entirely live just because it's still in the
+file.
+
+## Executable Persistence
+
+The installed CLI implements this interface across sessions. Use
+`sia capture --signal <type> --context <text> --severity <level>
+--error-class <class>` for a DEVIATION and `sia record --outcome pass ...` for
+a PASS. Events append to `.sia/events.jsonl`; approved provenance-bearing rules
+live in `.sia/rules.json`; `sia preflight` loads applicable active rules; and
+`sia convergence` computes overall and per-error-class rates. This executable
+record is the durable source for the prose loop above.

sia_package-0.2.0/guides/questioning-and-approval.md

@@ -0,0 +1,44 @@
+# Questioning Mode & Approval Gates
+
+Applies to every stage of the pipeline in `../AGENT.md`. This is the
+mechanism that prevents premature completion — the failure mode SIA
+exists to eliminate.
+
+## Batching Questions
+
+- Ask *what* the user wants, not *how* to implement it.
+- Collect every clarifying question you have for the current stage and
+  ask them together, in one message — never drip-feed interruptions.
+- If new questions surface mid-stage, hold them until the next natural
+  batch point rather than interrupting again immediately, unless
+  continuing without an answer risks an irreversible action.
+
+## Severity Table
+
+Every proposed action is tagged with a severity before it is presented:
+
+| Severity | Examples | Behaviour |
+|----------|----------|-----------|
+| Low | Rename a variable, fix a typo, reword a sentence in a draft | Proceed silently |
+| Medium | Change a component's public props, alter an API shape, restructure a document section | Flag and batch for review |
+| High | Delete data, change auth logic, modify production config, restructure a shared interface, send or publish a deliverable externally | Always require explicit approval before proceeding |
+
+The threshold is configurable per project (state it in that project's
+own `AGENT.md`) — a greenfield prototype can run more autonomously than
+a production system with real users or a deliverable going to an
+external client.
+
+## Non-Negotiable Rules
+
+1. Never assume on a non-trivial decision.
+2. Never delete, replace, or restructure anything on your own
+   initiative — propose an impact statement, then wait.
+3. Never declare a stage "done" until its acceptance criteria are met
+   *and* the user has approved any high-impact work within it.
+4. Surface creative/design decisions as options with trade-offs; narrow
+   the decision space, don't make the final call yourself.
+
+An impact statement states the concrete consequence, not just the
+action: "I'm going to delete the `users` table and recreate it with a
+new schema. This will permanently drop all existing data. Proceed?" —
+not "I'm updating the schema."

sia_package-0.2.0/guides/security-gate.md

@@ -0,0 +1,40 @@
+# Security Gate
+
+The one fixed, reused pack in SIA. Threat classes don't vary per project
+the way specs do, so this checklist is loaded as-is — never regenerated.
+
+## When To Load This Gate
+
+Load this gate only when intake (`../AGENT.md` §Pipeline step 2) has
+identified the current project as a software project — greenfield or
+brownfield. Document/deck-prep and design projects do not load this
+gate; their equivalent risk (leaking confidential material into a public
+deliverable) is handled by the approval-gate severity table in
+`questioning-and-approval.md` instead.
+
+Run this checklist before any generated code is applied or executed —
+not just before merge.
+
+## Threat Classes
+
+- **XSS / JS injection** — `innerHTML`, `eval`, unsanitized input
+  rendered into the DOM.
+- **SQL / command injection** — string-concatenated queries, template
+  literals or shell calls built from raw user input.
+- **Prompt injection / jailbreak patterns** aimed at the LLM itself —
+  instructions embedded in untrusted data (user messages, fetched
+  documents, tool output) attempting to override system rules.
+- **Hard-coded secrets** — API keys, tokens in URLs, credentials
+  committed to source, missing CORS/auth checks.
+- **Unescaped LLM output** rendered to a user without sanitization.
+
+## On A Finding
+
+1. Do not apply the change as generated. Fix it before presenting it.
+2. Log what pattern caused it via `capture(signal_type, context, severity)`
+   (see `../capture-interface.md`), with `signal_type` set to
+   `security-finding`.
+3. Propose the finding as a standing rule for this project's own
+   `AGENT.md` (see `writing-agent-md.md`), so this project accumulates
+   its own vulnerability profile instead of re-deriving the same finding
+   next session.