Correct repo flavor to product; add SCOPE, AGENTS, classification

fix-consistency surfaced that GOAL.md's `repo_flavor: project` was wrong.
project-repository-flavor_v0.1.md reserves the prj- flavor for bounded
cross-repo coordination efforts and says durable products use INTENT.md and an
ordinary category. informed-decision is a durable product, so the C-35
"prj- flavor forbids shipping both INTENT.md and GOAL.md" contradiction was
self-inflicted rather than a real conflict.

- .repo-classification.yaml: category product, domain infotech.
- GOAL.md: drop repo_flavor/project_status, add a flavor note explaining that
  GOAL.md is retained as the stage statement alongside a stable INTENT.md.
- SCOPE.md: honestly empty — states that nothing is implemented and that
  INFD-WP-0001-T06 rewrites it after the gate-house ruling and the specs.
- AGENTS.md: shared State Hub / session / workplan boilerplate, plus the hard
  rules for this repository — never decide, never own approval state, never
  invent identity, never let awareness enter view_hash, never let an agent
  bind, never fork the schema, fail closed.
- INFD-WP-0001: T01 records both corrections; T06 now rewrites SCOPE.md.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568

SCOPE.md

@@ -0,0 +1,75 @@
+# SCOPE
+
+> Implemented-and-first-cut boundary for agents and contributors. Aspirational
+> direction belongs in `INTENT.md`; the current stage belongs in `GOAL.md`;
+> current work and gates belong in `workplans/`.
+
+## Status — 2026-09-09
+
+**Nothing is implemented.** This repository currently contains founding
+documents, the preserved founding exploration under `history/`, and
+`workplans/INFD-WP-0001`. There is no package, no service, no deployment, and
+no UI.
+
+This file exists because the Repo Manager requires it and because an honest
+empty boundary is more useful than an imagined one. It is rewritten in
+`INFD-WP-0001-T06`, once the `gate-house` layer ruling (T02) and the
+specifications (T03–T05) have fixed the real boundary. **Do not read the
+sections below as describing working code.**
+
+## One-liner
+
+informed-decision is the presentation and binding surface for decisions: it
+renders a Decision Memo to the human who holds the mandate, records what was
+shown, and binds their identity to the act — and owns the browser-facing
+approver UI that `approval-engine` deliberately does not contain.
+
+## Core Idea
+
+A decision surface is not a workflow engine and not a decision point. This
+repository owns the Decision Memo object, the presentation record, the
+canonicalization that produces `view_hash` / `awareness_hash`, the disposition
+vocabulary, and the evidence bundle export. It does not evaluate whether an act
+is permitted, does not hold approval current-state, and does not archive the
+trail.
+
+## In Scope — first cut (Stage 1, not yet built)
+
+- The Decision Memo object and its versions, promoted from
+  `history/20260909-initial-exploration/` into governed `schemas/`.
+- Canonicalization of the binding and awareness documents, with the four
+  isolation vectors under test.
+- The presentation record: what was rendered, to whom, when, in which locale
+  and UI release.
+- Required-highlight acknowledgment as a precondition of binding.
+- The disposition vocabulary — `comment`, `discuss`, `return`, `forward`,
+  `escalate`, `acknowledge`, `accept`, `decline`, `withdraw`, `configure` —
+  and its legality tables.
+- The browser-facing OIDC client for human principals: authorization-code +
+  PKCE against `key-cape`, yielding a token with `aud=approval-engine`,
+  `principal_type: human`, scope `approval:approve`.
+- An L3 approver surface calling `approval-engine`'s approval-entry mutation.
+- The evidence bundle as an offline-verifiable export.
+
+## Out of Scope
+
+- Authorization decisions — `access-engine`, always and only (statute §6).
+- The approval object, its state machine, validity and consumption —
+  `approval-engine`. This surface never caches validity, never infers
+  consumption, never requests `approval:consume`.
+- Approval doctrine: which acts require approval, how many approvers, which
+  separations of duty — `gate-house`.
+- Identity and authentication — `key-cape`. Identity is imported, never
+  invented here.
+- The evidence archive — `audit-core`. This repository emits and exports.
+- Credentials materialized after a decision — `secrets-engine`.
+- Notification transport, ticketing, and general workflow.
+- L4/L5, QES, QTSP integration, qualified archival retention.
+- The mandate graph. Stage 1 routes to a named approver and does not maintain a
+  map of who may bind what — a known, accepted limitation recorded in `GOAL.md`.
+
+## Layer placement
+
+**Provisional and unratified.** The working position is PEP-shaped under
+statute §6.4 and companion §5. `layer.yaml` does not exist yet and is written
+from the `gate-house` ruling in `INFD-WP-0001-T02`, not from this file.