ecoportal-api-graphql 1.3.13 → 1.3.16

data/docs/self-docs/COMPLIANCE.md

@@ -1,79 +0,0 @@
----
-schema_version: "1.1"
-repo: "ecoportal-api-graphql"
-doc: compliance
-last_generated: "2026-07-09"
-source_head: "3f7b877"
-review_status: draft   # audit answers MUST come from 'reviewed' docs only -- a human sets this
----
-
-# Compliance -- ecoportal-api-graphql
-
-**Purpose:** the audit / privacy / ISO-27001 surface for this project. It lets ROVO (over the EP Projects
-Register) answer compliance questions across the fleet. **Trust rule:** everything here separates
-EVIDENCE (a fact or link) from INTENT (planned); a reviewer must set `review_status: reviewed` before an
-answer built on this doc is used for audit or re-certification -- a confident answer on unreviewed content
-would mislead an auditor.
-
-> This document is DRAFT and was composed from the repo's own context (CLAUDE.md, the
-> `.ai-assistance/code/` specs, and the active project INTENT). Fields marked PLANNED or "human to
-> confirm" MUST be verified by the repo owner before any audit use.
-
-## ISO 27001
-
-This is a Ruby client library (a gem), not a hosted service; it holds no infrastructure of its own and
-introduces no independent ISO-27001 control surface. Its compliance posture is inherited from (a) the
-ecoPortal platform it authenticates against and (b) the consuming project's runtime environment. The
-control this repo DOES own is access-scoping of the automation that uses it.
-
-| Control area | Status (evidence / planned) | Evidence link |
-|---|---|---|
-| Access control / least privilege (A.9) | EVIDENCE: the template-automation work is required to run under a per-org SERVICE ACCOUNT scoped to templates/org-config only, with page records structurally out of scope by credential grant (ep-ai-standards `security/ai-service-account-scope`). | `.ai-assistance/projects/template-automatic-build-maintenance/INTENT.md`; `security/ai-service-account-scope` standard |
-| Change control (A.12.1) | EVIDENCE: no silent breaking changes -- public-interface changes are recorded in the active project's DECISIONS log and confirmed with the developer; semver + CHANGELOG. | `CLAUDE.md`; `CHANGELOG.md` |
-| Input validation (A.14.2) | EVIDENCE: `no_schema: true` disables build-time schema validation; the compensating control is a query validator now covering mutations. | `.ai-assistance/code/` (query validator); `ARCHITECTURE.md` |
-| Auditability of automated changes | PLANNED / human to confirm: template BUILD/diff emits an ordered `WorkflowCommand` batch and a pairing ledger; whether that stream is retained as an audit trail for re-certification needs owner confirmation. | `.ai-assistance/code/diff_pairing_engine.md` |
-
-## Data handled
-
-The gem can read and write live ecoPortal domain objects through the API. Data classification is by
-CAPABILITY (what the client can touch), then narrowed by the credential scope in use at runtime.
-
-| Data class (none/team/customer/PII) | What / where | Treatment + retention | Exposed? (how) |
-|---|---|---|---|
-| Customer data + PII | Page records read/written via the GraphQL API (can contain personal data). | In-memory only during a client session; the gem persists nothing itself. Retention lives in the ecoPortal platform, not here. | Not exposed by the gem beyond the authenticated API call. Read/write capability is gated by the runtime credential; template-automation deliberately excludes page records by service-account scope. |
-| Customer/org config (non-PII) | Templates, location structures, org configuration. | In-memory during a session; changes applied via `WorkflowCommand` batches. Retention in the platform. | Only via the authenticated API; this is the scope the template-automation service account is limited to. |
-| Team-only | `.env` credentials for live tests (`ANTHROPIC_API_KEY`, ecoPortal creds via dotenv). | Local `.env`, gitignored; loaded only for `--tag live` specs. | Not committed; not exposed. |
-
-## Third-party vendors in the data path
-
-| Vendor | What data | Disclosed to end users? | Notes |
-|---|---|---|---|
-| Anthropic (Claude) | Only for `--tag live` AI tests, gated by `ANTHROPIC_API_KEY`. No customer page data is sent as part of normal gem operation. | N/A -- development-time only, not a production data path. | Live AI tests are opt-in; the gem's runtime API client does not call any LLM. Human to confirm no PII appears in live-test fixtures. |
-
-No customer/PII data leaves the ecoPortal boundary through this gem in normal operation: it is a client
-for ecoPortal's own API, not a bridge to an external SaaS.
-
-## PII / data-leak controls
-
-- **Credential scope (primary control):** the template-automation service account is scoped to
-  templates/org-config only, so page records (customer data + PII) are out of reach by GRANT, not by
-  instruction (ep-ai-standards `security/ai-service-account-scope`). This is the load-bearing leak
-  control.
-- **`org_id` scoping:** every client session is bound to a single org context; cross-org reads require
-  distinct credentials.
-- **No local persistence:** the gem holds data in memory for the session and writes nothing to disk;
-  there is no cache or log of customer records to leak.
-- **`.env` gitignored:** credentials for live tests never enter version control.
-- **Query validator:** compensates for `no_schema: true` by catching malformed queries/mutations before
-  they hit the live API.
-
-## AI-generated content
-
-- Externally-exposed AI content: **no.** The gem produces no customer-facing or publicly-exposed AI
-  content. AI assistance is confined to development (code generation, template-automation planning) and
-  `--tag live` AI tests; its output is reviewed code and internal artefacts, not exposed to end users.
-- Marked as AI-generated: **N/A** for external content. Internally, AI-assisted commits follow the
-  developer-only authorship convention (no `Co-Authored-By` unless requested), and Gemini responses must
-  be verified against actual code before applying.
-- Review process: standard MR review; public-interface changes additionally logged in the active
-  project's DECISIONS log and confirmed with the developer.

data/docs/self-docs/CONVENTIONS.md

@@ -1,74 +0,0 @@
----
-schema_version: "1.1"
-repo: "ecoportal-api-graphql"
-doc: conventions
-last_generated: "2026-07-09"
-source_head: "3f7b877"
-review_status: draft
----
-
-# Conventions -- ecoportal-api-graphql
-
-**Source of truth:** `.rubocop.yml` (repo root) and `CLAUDE.md`. There is no `ai-discovery`
-`conventions.md` in this repo; the below is composed from `.rubocop.yml`, `CLAUDE.md`, and observed
-git history, not re-derived from code.
-
-## Code style
-
-- Indentation: 2 spaces (Ruby default; no override in `.rubocop.yml`).
-- Quotes: not enforced -- `Style/StringLiterals` is disabled, so single and double quotes are both
-  accepted.
-- Line length: unlimited -- `Layout/LineLength` is disabled.
-- Frozen string literal comment: not required (`Style/FrozenStringLiteralComment` disabled).
-- Hash alignment: table style for both colon and hash-rocket (`Layout/HashAlignment`).
-- Dot position: trailing (`Layout/DotPosition`).
-- Alias: prefer `alias_method` (`Style/Alias`).
-- Notable relaxed metrics: `ClassLength` 350, `ModuleLength` 400, `MethodLength` 100,
-  `AbcSize` 30, `CyclomaticComplexity`/`PerceivedComplexity` 30, `ParameterLists` 5.
-- Naming exceptions: camelCase method/variable names are allowed where they mirror GraphQL/Relay
-  schema fields verbatim (`Naming/MethodName` disabled; `clientMutationId` allow-listed). This is
-  intentional -- the client mirrors the schema.
-- Rubocop compliance is required for all generated Ruby: run `bundle exec rubocop <file>` to verify.
-
-## Branch naming
-
-Type-prefixed, slash-separated. Observed prefixes in the branch list and history:
-`feat/<slug>`, `fix/<slug>`, `docs/<slug>`, `chore/<slug>`, and longer-lived `feature/<slug>`
-branches for multi-phase work. Note: `pages` is a long-running primary development branch that
-predates the prefix convention.
-
-## Commit message style
-
-Conventional Commits: `type(scope): message`. Observed types include `feat`, `fix`, `docs`,
-`chore`, and `merge`. Scopes are area-based, e.g. `feat(diff/builder):`, `docs(worklog):`,
-`chore(release):`, `docs(template-automation):`. Release commits follow
-`chore(release): vX.Y.Z ...`.
-
-## Test conventions
-
-- Runner: RSpec (`bundle exec rspec`).
-- Placement: spec files mirror the `lib/` structure under `spec/` (e.g.
-  `spec/ecoportal/api/graphql/input/search_conf_spec.rb`).
-- Live tests: tagged `--tag live`; `.env` is loaded via `dotenv` in `spec_helper.rb`
-  (needs `ANTHROPIC_API_KEY` for live AI tests).
-- Manual integration scripts live under `tests/` (separate from the RSpec suite).
-- Coverage is known to be sparse in subdirectories (see `.ai-assistance/code/spec_coverage.md`).
-
-## Project-specific rules
-
-From `CLAUDE.md`:
-
-- Namespace: `Ecoportal::API::GraphQL` (capital G, Q, L); file paths use lowercase `graphql/`.
-- File/class mirroring: file path mirrors the class namespace exactly.
-- Code-spec docs: for every area analysed, a corresponding `.ai-assistance/code/<area>.md` should
-  exist or be created/updated.
-- No silent breaking changes: any change to the gem's public interface must be noted in the active
-  project's DECISIONS log and confirmed with the developer. Backwards compatibility with
-  `eco-helpers` must be preserved unless explicitly broken.
-- Gemini responses must be verified against actual code before applying.
-- Commit authorship: developer only by default; do not add `Co-Authored-By: Claude ...` unless the
-  developer explicitly requests it.
-- Verified Platform Knowledge: consult `.ai-assistance/code/ecoPortal_architecture/` before
-  implementing platform logic; record newly confirmed platform facts there with evidence (ADR-012).
-- Working-tree safety: follow `.ai-assistance/conventions/code-working-tree-protocol.md` (bridge
-  LOCK, commit overlapping unstaged changes as `wip:` first) before modifying files.

data/docs/self-docs/INTEGRATIONS.md

@@ -1,65 +0,0 @@
----
-schema_version: "1.1"
-repo: "ecoportal-api-graphql"
-doc: integrations
-last_generated: "2026-07-09"
-source_head: "3f7b877"
-review_status: draft
----
-
-# Integrations -- ecoportal-api-graphql
-
-**Purpose:** the ties this project has to other systems and repos. This is the section the central
-hub uses to trace inter-project dependencies and surface reuse (ADR-015 Section 5). It records, per
-tie, the DATA that flows and the PERMISSIONS required -- feeding the compliance (vendor/PII) and the
-cross-project-permissions questions. Detailed data-handling lives in `COMPLIANCE.md`.
-
-## External services
-
-| Service | Purpose | Data sent (class + PII?) | Auth / permissions (scopes) |
-|---|---|---|---|
-| ecoPortal GraphQL API | The API this gem is a client for -- reads/writes pages, templates, location structures, contractor entities, actions, organizations. | Customer data + PII: page records can contain personal data. Also template/org-config data (non-PII). The gem is a full-access client by capability; the active template-automation work restricts itself to templates/org-config only by SERVICE-ACCOUNT grant. | OAuth via `Common::GraphQL::AuthService`, scoped by `org_id`; per-environment host (e.g. live.ecoportal.com). `no_schema: true` (no introspection). Credential scope is the load-bearing control -- see COMPLIANCE.md. |
-| ecoPortal REST API (v2) | Underlying REST infrastructure the GraphQL layer builds on and stays compatible with via the `Compat` layer. | Same classes as above (indirect, via `ecoportal-api-v2`). | Same OAuth / org-scoped runtime credentials; provided through the upstream `ecoportal-api-v2` gem. |
-
-## Upstream dependencies (repos we depend on)
-
-| Repo / package | What we use it for | Permission/scope required (if any) |
-|---|---|---|
-| `ecoportal-api` | REST API base: auth, org context, base models, and the `Ecoportal::API::Common` namespace this gem extends. Team-managed. | None beyond the runtime ecoPortal API credentials (email/pass/org_id/host) passed at instantiation. |
-| `ecoportal-api-v2` | REST API v2 layer (Page, Register, etc.); required by the entry point. Team-managed. Being retired over time. | Same runtime ecoPortal API credentials. |
-| `graphlient` | Friendly GraphQL DSL/client wrapper; `Common::GraphQL::Client` inherits from `Graphlient::Client`. Active fork owned by the team (upstream: `ashkan18/graphlient`). | None (library dependency). |
-| `graphql-client` | Low-level GraphQL HTTP + parsing, pulled in transitively via graphlient. Fork for upstream contribution only (upstream: `github-community-projects/graphql-client`); not team-maintained. | None (library dependency). |
-| `graphql` (graphql-ruby) | Schema definition/execution engine (`rmosolgo/graphql-ruby`); external, read-only reference. Used server-side by ecoPortal; client-side usage here is indirect. | None (library dependency). |
-
-## Downstream consumers (who depends on us)
-
-- `eco-helpers` -- the primary consumer; an integration-script framework for the ecoPortal
-  Integrations Team. It requires this gem (`ecoportal-api-graphql ~> 1.3, >= 1.3.4`) and relies on
-  the `Compat` layer to treat `graphql` as a drop-in for the older `apiv2` interface. Backwards
-  compatibility with `eco-helpers` must be preserved unless explicitly broken.
-- `ecoportal-qa` -- consumes the gem to verify template deploys (the "verify" step of the template
-  build-and-maintenance pipeline; a `DryRunClient` and `Publisher` were built there). The
-  template-automation project aims to tighten `ecoportal-qa` to consume the gem's page-model.
-
-## Key package dependencies
-
-From `ecoportal-api-graphql.gemspec` (runtime):
-
-- `ecoportal-api` `~> 0.10, >= 0.10.16`
-- `ecoportal-api-v2` `~> 3.3, >= 3.3.3`
-- `graphlient` `>= 0.8.0, < 0.9`
-
-Development: `rspec`, `rubocop` (+ `rubocop-rake`), `rake`, `pry`, `yard`, `redcarpet`.
-Required Ruby: `>= 3.2.2`.
-
-## Feature-request-not-rebuild note
-
-- The template build-and-maintenance capability is developed here in the gem (mechanics: read
-  model, command vocabulary, BUILD emitter, diff, apply, pairing engine + ledger). Orchestration
-  (interactive assisted-resolution UX, session flows) belongs in `eco-helpers`, and verification in
-  `ecoportal-qa`. Before building template/diff/deploy mechanics elsewhere, raise a feature request
-  against this gem rather than duplicating the emission layer.
-- The active template automation is a concrete consumer of the ep-ai-standards
-  `security/ai-service-account-scope` standard: it must authenticate as a dedicated per-org SERVICE
-  ACCOUNT scoped to templates/org-config only, with page records (customer data + PII) structurally
-  out of scope by credential grant. See `.ai-assistance/projects/template-automatic-build-maintenance/INTENT.md`.

data/docs/self-docs/OPERATIONS.md

@@ -1,76 +0,0 @@
----
-schema_version: "1.1"
-repo: "ecoportal-api-graphql"
-doc: operations
-last_generated: "2026-07-09"
-source_head: "3f7b877"
-review_status: draft
----
-
-# Operations -- ecoportal-api-graphql
-
-**Purpose:** the infrastructure / exposure / value surface for DevOps and Engineering. It lets ROVO answer
-"what infrastructure is involved, is it behind Cloudflare, what governs its flows, and is it worth it?"
-Same trust rule as COMPLIANCE.md: separate EVIDENCE from INTENT; audit answers use `reviewed` docs only.
-
-> This document is DRAFT and composed from the repo's own context. It is a client LIBRARY (a gem): it has
-> no infrastructure or public exposure of its own. Value/KPI figures below are unmeasured placeholders for
-> the repo owner to fill; do not cite them as measured until reviewed.
-
-## Infrastructure inventory
-
-This project is a Ruby gem distributed as source/package -- it runs INSIDE whatever process requires it
-(e.g. an `eco-helpers` integration script). It owns no compute, storage, or queue of its own.
-
-| Component | Type (compute/store/queue/...) | Where hosted | Notes |
-|---|---|---|---|
-| The gem itself | library (no runtime infra) | Consumer's process / developer machine / CI | No servers, no data stores; loaded via Bundler into a host process. |
-| ecoPortal GraphQL API | external service (dependency) | ecoPortal platform, per-environment host (e.g. live.ecoportal.com) | The gem is a CLIENT of this; the API's infrastructure is owned by the platform, not this repo. |
-| RubyGems / Bundler | package distribution | RubyGems (or team gem source) | Distribution channel for the gem. |
-
-## Public exposure
-
-**Nothing in this repo is publicly exposed.** It is a client library with no listening endpoint, no
-domain, and no inbound surface. It makes OUTBOUND authenticated calls to the ecoPortal GraphQL API; the
-public-exposure and Cloudflare/WAF posture of that API belongs to the ecoPortal platform's own OPERATIONS
-doc, not to this gem.
-
-| Public domain / endpoint | Behind Cloudflare? | Security rules governing the flow |
-|---|---|---|
-| (none -- library, no inbound surface) | N/A | Outbound only: OAuth-authenticated, `org_id`-scoped calls to the ecoPortal GraphQL API over HTTPS. |
-
-## DevOps audit runbook
-
-How to check/verify this project autonomously:
-
-- **Build / install:** `bundle install`; gem spec is `ecoportal-api-graphql.gemspec`; version constant
-  `Ecoportal::API::GRAPQL_VERSION`.
-- **Tests:** `bundle exec rspec` for the unit suite; `bundle exec rspec --tag live` for live-API/AI tests
-  (requires `.env` with `ANTHROPIC_API_KEY` and ecoPortal credentials, loaded via dotenv).
-- **Lint:** `bundle exec rubocop <file>` -- rubocop compliance is required for all generated Ruby
-  (config in `.rubocop.yml`).
-- **CI:** no CI config file was detected at the repo root by the scanner (`ci_files: []`). Human to
-  confirm whether CI runs elsewhere (e.g. a GitLab CI defined outside the root) or is absent.
-- **Version / release check:** `CHANGELOG.md` is authoritative; releases follow
-  `chore(release): vX.Y.Z`. Recent releases raised the `ecoportal-api-v2` floor to fix version-drift
-  crashes -- verify the dependency floors in the gemspec match the CHANGELOG.
-- **Deeper docs:** `.ai-assistance/code/` (code-specs, dependency map, diff/build engine, schema
-  analysis) is the detailed runbook for engineers; `.ai-assistance/code/ecoPortal_architecture/` is the
-  verified platform knowledge base.
-
-## Value & KPIs
-
-No usage KPIs are instrumented in this repo today. The value narrative below is qualitative /
-estimated; the repo owner should replace estimates with measured figures (or a dashboard link) before
-these are treated as evidence.
-
-| Metric | Value (measured/estimated) | Source / dashboard |
-|---|---|---|
-| Templates targeted for programmatic build/maintenance | ~300+ (estimated, project scope) | `.ai-assistance/projects/template-automatic-build-maintenance/INTENT.md` |
-| Hours saved / delivery-speed gain | Not measured | -- (owner to instrument) |
-| Active monitoring | None in-repo; staleness of these self-docs is detectable via `source_head` vs git head | `self-docs-index.json` |
-| Cost-vs-return | Not measured | -- (owner to instrument) |
-
-**Coverage-on-neglect:** these self-docs carry a `source_head` and a per-doc `content_hash` in
-`self-docs-index.json`, so the hub and `project-review` can flag them stale rather than silently trusting
-them.

data/docs/self-docs/OVERVIEW.md

@@ -1,64 +0,0 @@
----
-schema_version: "1.1"
-repo: "ecoportal-api-graphql"
-doc: overview
-last_generated: "2026-07-09"
-source_head: "3f7b877"
-review_status: draft   # draft | reviewed  (only a human sets 'reviewed')
----
-
-# Overview -- ecoportal-api-graphql
-
-## What this project is
-
-`ecoportal-api-graphql` is a Ruby gem that provides a GraphQL client layer for the ecoPortal
-GraphQL API. It wraps `graphlient` (which itself wraps `graphql-client`) and builds a structured
-layer of models, queries, mutations, fragments, inputs, payloads, and builders on top of it. It
-sits between the upstream ecoPortal REST API gems and downstream consumer code, exposing a
-developer-facing facade for reading and writing ecoPortal domain objects (pages, templates,
-location structures, contractor entities, actions, and organizations).
-
-## Who it serves
-
-Team members -- specifically the ecoPortal Integrations Team and internal script authors. The gem
-is a developer-facing library, not a customer-facing product; its primary consumer is the
-`eco-helpers` integration-script framework. Because it can read and write live customer data
-(page records) through the API, AI caution levels are elevated: the active template-automation
-work is deliberately scoped to a service account covering templates/org-config only, keeping page
-records (customer data + PII) structurally out of scope.
-
-## Current priority
-
-Template Automatic Build and Maintenance (the #1-priority project). This merges the former
-`template-diff-deploy` and `template-maintenance` efforts into one lifecycle: build/maintain 300+
-templates programmatically (a CSV-to-templates pipeline, deadline approximately September 2026)
-and make UAT-to-PROD change replication smooth via a diff/pairing/deploy/verify pipeline. Both
-halves share one emission layer (an ordered `WorkflowCommand` batch with `placeholderId`
-threading).
-
-## At a glance
-
-- Repo type: ruby-gem
-- Primary language / runtime: Ruby (>= 3.2.2)
-- Entry points: `require 'ecoportal/api-graphql'` -> `lib/ecoportal/api-graphql.rb` ->
-  `Ecoportal::API::GraphQL` (`lib/ecoportal/api/graphql.rb`)
-
-## Discovery & access
-
-Access model: **on-request, developer-scoped** -- this is a Ruby gem, not a self-serve product. It
-reaches its users (the ecoPortal Integrations Team and internal script authors) by being declared as
-a dependency in a consuming project's Gemfile/gemspec (e.g. `eco-helpers ~> 1.3, >= 1.3.4`), not by
-a public listing or an end-user-facing install. Developers learn it exists through the team's
-integration-gem stack documentation (`.ai-assistance/code/ecoPortal_architecture/11_integration_gems.md`),
-the repo README, and this self-docs set once mirrored to the EP Projects Register. There is no
-customer-facing discovery surface: end customers never interact with the gem directly; they see only
-the ecoPortal platform it talks to.
-
-## Related self-docs
-
-- Architecture: `ARCHITECTURE.md`
-- Conventions: `CONVENTIONS.md`
-- Integrations: `INTEGRATIONS.md`
-- Status: `STATUS.md`
-- Compliance: `COMPLIANCE.md`
-- Operations: `OPERATIONS.md`

data/docs/self-docs/STATUS.md

@@ -1,73 +0,0 @@
----
-schema_version: "1.1"
-repo: "ecoportal-api-graphql"
-doc: status
-last_generated: "2026-07-09"
-source_head: "3f7b877"
-review_status: draft
----
-
-# Status -- ecoportal-api-graphql
-
-**Note:** this is the most time-sensitive self-doc. Refresh it at cycle-end and after structural
-changes. Staleness is detectable via `source_head` vs the current git head.
-
-## Active work
-
-Hot paths from the scanner (`lib`, `.ai-assistance`, `spec`, `docs`) plus the active project
-intent. The #1-priority project is Template Automatic Build and Maintenance (see
-`.ai-assistance/projects/template-automatic-build-maintenance/INTENT.md`), which merges the former
-`template-diff-deploy` and `template-maintenance` projects into one lifecycle sharing a single
-`WorkflowCommand` emission layer:
-
-- BUILD: build/maintain 300+ templates programmatically (CSV-to-templates pipeline, deadline
-  approximately September 2026) via a declarative spec -> `Builder::TemplateBuilder` -> ordered
-  command batch -> apply -> verify. Emitter is ready; live characterization is pending sandbox
-  service-account credentials.
-- MAINTAIN / DIFF-DEPLOY: UAT-to-PROD change replication -- detect (diff) -> review -> deploy
-  (delta commands) -> verify -> monitor. Self-version diff, the pairing engine + ledger, diff
-  modalities/`Diff::Strategy`, the cross-object diff path, and `Change`-to-`WorkflowCommand`
-  synthesis are done; the interactive assisted-pairing UX (in `eco-helpers`) is pending.
-- Recent fragment-convention work: Action/ContractorEntity mutations migrated to the spread
-  convention; the query validator now covers mutations.
-
-## Migration state (if any)
-
-- ooze/pages GraphQL-native migration and the api-v2-to-graphql migration are ongoing themes (see
-  `.ai-assistance/projects/ooze-graphql-native-migration/` and `.../api-v2-to-graphql-migration/`).
-  `ecoportal-api-v2` is being retired over time; the `Compat` layer preserves the v2 interface for
-  `eco-helpers` during the transition.
-- Recent releases addressed stale-release drift: v1.3.11 raised the `ecoportal-api-v2` floor to
-  `>= 3.3.3` to fix a Ruby-3.x cascade after three live crashes were traced to version drift.
-
-## Known risks
-
-- Live customer data exposure: the gem can read/write page records (PII). The template automation
-  is the mitigation lever -- it MUST run under a service account scoped to templates/org-config
-  only, enforced by credential grant, not by instruction (ep-ai-standards
-  `security/ai-service-account-scope`). Provisioning that concrete grant is now this repo's work,
-  not a platform blocker.
-- Backwards compatibility with `eco-helpers` is a hard constraint; public-interface changes must be
-  logged in the active project's DECISIONS log and confirmed with the developer.
-- `no_schema: true` means queries are not validated against a schema at build time -- a query
-  validator (now covering mutations) is the compensating control.
-- Spec coverage is sparse in subdirectories (`.ai-assistance/code/spec_coverage.md`).
-
-## Open questions
-
-- No CI config was detected at the repo root; whether CI runs elsewhere or is absent needs human
-  confirmation.
-- The cross-object equivalence-matching (pairing) problem has no stable identity across independent
-  Mongo objects; it depends partly on Product's forthcoming template-entity-id, which this gem
-  bridges and feeds but does not own.
-- Workflow-config-per-stage diff is out of scope until the `PagesWorkflow.stages` read model is
-  completed.
-
-## Recent changes
-
-Upgraded the self-docs set to schema 1.1 (audit/compliance surface): added `COMPLIANCE.md` and
-`OPERATIONS.md`, enriched `INTEGRATIONS.md` (data class + PII + permissions per tie) and `OVERVIEW.md`
-(Discovery & access), and bumped all docs to `source_head` `3f7b877`. Everything remains
-`review_status: draft` -- a human must set `reviewed` before any audit use. Prior state: first
-generation at git head `2abd6fc` (EP Projects Register pilot). The machine-readable delta is in
-`CHANGES.jsonl`.

data/docs/self-docs/self-docs-index.json

@@ -1,51 +0,0 @@
-{
-  "schema_version": "1.1",
-  "generated_at": "2026-07-09T07:08:00Z",
-  "repo_name": "ecoportal-api-graphql",
-  "repo_type": "ruby-gem",
-  "head": "3f7b877",
-  "docs": [
-    {
-      "file": "docs/self-docs/OVERVIEW.md",
-      "purpose": "What the project is, who it serves, current priority, discovery & access",
-      "exists": true,
-      "content_hash": "c403012498ab9247"
-    },
-    {
-      "file": "docs/self-docs/ARCHITECTURE.md",
-      "purpose": "Top-level structure, key components, how they fit",
-      "exists": true,
-      "content_hash": "ad05f25b95b49c00"
-    },
-    {
-      "file": "docs/self-docs/CONVENTIONS.md",
-      "purpose": "Coding style, branch naming, commit style, test conventions",
-      "exists": true,
-      "content_hash": "1649159eb799a7b8"
-    },
-    {
-      "file": "docs/self-docs/INTEGRATIONS.md",
-      "purpose": "External services + data + permissions, upstream/downstream repos",
-      "exists": true,
-      "content_hash": "d271ac76361e4638"
-    },
-    {
-      "file": "docs/self-docs/STATUS.md",
-      "purpose": "Active work, migration state, known risks, open questions",
-      "exists": true,
-      "content_hash": "1acf51a3e7822dfb"
-    },
-    {
-      "file": "docs/self-docs/COMPLIANCE.md",
-      "purpose": "ISO-27001/audit, data classes + PII, vendors, AI content, leak controls",
-      "exists": true,
-      "content_hash": "1e72c2356b4e3579"
-    },
-    {
-      "file": "docs/self-docs/OPERATIONS.md",
-      "purpose": "Infrastructure, public exposure + Cloudflare, DevOps audit, usage KPIs",
-      "exists": true,
-      "content_hash": "878b50d02339acb7"
-    }
-  ]
-}