Vault Update Plan for Client Feedback

Status. Proposed design only. Nothing in this vault is DG client approval. No application, service or test has been executed; every scenario is Not executed. Fees and dates are open.

Vault update plan for the new client documents

Draft for review. Nothing in the vault has been changed by this plan, and no GitHub issue or epic should be filed until the owner accepts it. The plan was written after reading all four files in docs/:

Short name	File	Notes
Idea	docs/high-level-idea.md	Three paragraphs; the owner’s summary of the new concept
Concept	docs/GGA_Concept_Note.pdf	2 pages, v1.0, 20 Oct 2026
Concept+Arch	docs/GGA_Concept_and_Architecture.docx	Concept, access levels, data rules, fee-after-value
Blueprint	docs/GGA_Development_Blueprint.pdf	20 pages, v1.0, 20 Oct 2026; roles, workflows, data, API, jobs, security, acceptance A1 to A12, launch decisions

Text extracts of the PDF and docx are in docs/extracted/ so reviewers can read them. Page numbers below are Blueprint pages unless stated.

1. What the new documents say (digest)

GGA is a business opportunity network connecting companies in India, Japan and South Korea. Independent country partners and companies submit opportunities (distribution, partnerships, services, technology, IP, talent, investment, other approved categories). GGA reviews each listing before publication. Anyone can browse public summaries; eligible registered companies see member details; contacts and documents are shared only with permission and mutual consent. Participation starts free; a voluntary INR 5 lakh annual contribution is offered after the company recognises value. The core exchange is reliable, current company data in return for useful opportunities and connections. First release targets 20 companies, expanding towards 100.

The Blueprint separates three kinds of statement, and the vault must keep that separation (p. 1):

1. Six fixed commitments (fortnightly one-hour session; six-monthly major event; mandatory high-quality company data with recurring confirmation; public summaries, member details and permission-based private sharing; Japan and South Korea partners source opportunities; INR 5 lakh voluntary contribution with payment not determining access; Anand convening, an operations owner doing routine work).
2. Proposed defaults (30-day confirmation, 14-day grace, day-7 and day-13 reminders, 14-day consent expiry, retry schedule, 24-hour and 1-hour event reminders, backup and performance targets, renewal invitation 30 days before expiry, renewal invoice at or after term end). These are configuration values for the pilot, not promises, and not decisions.
3. Launch decisions (p. 20: operating owner, founder time and funding, data freshness, consent and retention, contribution terms, categories and partners, technology and support, event production). Open until recorded.

2. Conflicts with the current vault (revision 1.3)

The current vault describes an invitation-only, private partnership exchange (the DG Partnership Exchange, Balanced option). The new documents describe a different product shape. The material conflicts:

#	Topic	Vault 1.3	New documents	Effect
C1	Audience	Invitation-only; no public indexing (Proposal-Decisions-D01-D10 D01, T01)	Public summaries for anyone, shareable public URLs, public API; self-registration with profile qualification (pp. 3, 10, 14)	Reverses D01; adds a public projection and an approved-public-only data path
C2	Membership model	DG approves and revokes membership; one company per user (Q01, Step-09-DG-Membership-Tool-and-Metadata)	Eligibility computed from verified contact, active membership, complete fields, current attestation, no hold; one selected company context per session; owner-approved colleague invites (pp. 3, 4)	Replaces the invitation and DG approval path with an eligibility engine and an operations hold
C3	Company data	Minimal profile; no verification engine	Mandatory structured profile, evidence, revenue band, versions, attestation, 30-day freshness and grace pause (pp. 4, 7)	New module; “overdue” now means stale profile, not an overdue action
C4	Documents	Document rooms and upload or verification engines are outside scope (Scope-Balanced-Manual-Additional)	Evidence files, private object storage, scanning, controlled downloads, grants (pp. 12, 13, 17)	Scope reversal
C5	Opportunity review	Company approver; DG review is added scope (Proposal-Decisions-D01-D10 D02)	Mandatory GGA operations review before publication; public, member and restricted layers; expiry required (p. 5)	Review authority changes
C6	Material revision	V1 stays live while V2 is reviewed (Versions-and-State)	A material amendment to a live offer pauses the affected listing until re-approved (p. 5)	Direct contradiction; needs an owner choice
C7	Engagement	Private questions, separate discussions, messages, next actions (Step-06-Questions-Interest-Discussions-Actions)	Pitch, owner decision, mutual consent, reciprocal contact release; open direct messaging deferred (pp. 1, 6)	Messaging and discussion model largely removed
C8	Payments	Billing and success fees outside every tier	Opt-in, finance approval, invoice, settlement, 12-month term, renewal; Finance role (p. 8)	Scope reversal
C9	DG paid services	S01 to S13 and 44 DG scenarios; Q12 to Q25	Not mentioned; no per-service sale	Whole track needs a disposition
C10	Roles	Owner or admin, approver, contributor, viewer, DG administrator	Public visitor, registered company, eligible owner or colleague, partner, operations owner, finance, technical administrator, Anand as convener (p. 3)	New role set
C11	Events and sessions	Manual weekly sessions (S10); no event software	Session occurrences, registration, capacity, waitlist, reminders, six-monthly event (p. 9)	New module
C12	Outcomes	”Reported outcomes” deferred (A07)	Outcome records, company-confirmed versus partner-reported, 14 and 45-day prompts (pp. 8, 16)	New module
C13	Delivery and commercial	Optimized, Balanced, Comprehensive options; fees and dates open (Delivery-Options-Comparison)	Five delivery stages; developer to give fixed scope after launch decisions (p. 19)	Commercial notes need a status; fees and dates stay open
C14	Acceptance IDs	A01 to A11, T01 to T40	A1 to A12 (different content)	ID collision risk; see section 5
C15	Outbox events	Four immediate business events; no digests	Many job types, retry 1 min, 5 min, 30 min, 2 h, then an exception queue (p. 16)	Extend, same transactional-outbox principle

Compatible ground (retain): transactional outbox; at-least-once delivery with duplicate protection and no exactly-once claim; deny-by-default server-side authorisation; immutable approved versions and exact-version approval; idempotency keys; rule-based matching with visible reasons and no AI in release one; English UI with Unicode storage; no native apps or open messaging; honesty about what review does and does not verify; separate provider ports.

3. Questions that must be answered before the vault is rewritten

These need the owner (and, where marked, the client). Each is a real fork, not a detail.

Q	Question	Why it blocks
N1	Is GGA the same client and engagement as the DG Partnership Exchange (a pivot), or a separate client? Does the new material supersede the 1.3 baseline or sit beside it?	Decides whether 1.3 is history or a live second baseline
N2	What happens to the DG paid-service track (S01 to S13, DG01 to DG44, Q12 to Q25)? Retire, park, or keep as a separate manual track?	44 scenarios and 14 pending decisions
N3	Are private questions, discussions, messages and next actions dropped, or kept alongside consented introductions?	Decides whether Step 06 and Step 08 survive
N4	Which governs a material edit to a live listing: pause (Blueprint p. 5) or V1 stays live (vault)?	C6
N5	Are payments in software scope (manual invoicing and reconciliation in the operations console, p. 8), and who approves the commercial change?	C8; commercial and legal impact
N6	Is public indexing and social preview of approved summaries intended (D01 reversal)?	C1
N7	Is the 1.3 commercial position (options, schedule, estimates) superseded by the Blueprint delivery plan?	C13
N8	Who is the named operations owner, finance approver and data owner? (Blueprint p. 20 requires one before launch.)	Roles cannot be written with real owners until named; the vault never invents an approver

4. Proposed approach: a second baseline beside revision 1.3

Recommendation: keep revision 1.3 untouched as history and add a new, versioned baseline. This follows the vault’s own rule (a later requirement gets a versioned record; history is never edited, Document-Lineage) and avoids breaking the validator.

Facts checked in the validator: it asserts exactly 84 scenario notes in 06-Scenarios, a fixed scenario index, and specific phrases on the start page. It also scans every note, including new folders, for broken links and for wording that claims results or client sign-off. A GS01.md placed in 06-Scenarios would be ignored by those counts and so escape validation; new scenarios get their own folder and their own validator (section 4.7).

4.1 New evidence folder 13-GGA-Network-Baseline/

Written once, then read-only (the protect hook gets one regex extension, below). Contents:

Note	Purpose
Source-Digest	One section per source file with checksum, page map and what each page establishes
Requirement-Register	Numbered requirements REQ-001… each tagged Fixed commitment, Proposed default (configurable), Launch decision, or Design proposal, with the page citation. Keeps the Blueprint’s own three-way distinction
Supersession-Register	Every old Tnn, DGnn, Qnn, Dnn, Ann, Snn, Step and architecture note mapped to Retained / Reframed / Superseded / Parked / Needs decision, with the reason and the replacing REQ. Generated first-pass, then reviewed by the owner
Scope-Release-One	Build now versus defer (Blueprint p. 1), replacing Scope-Balanced-Manual-Additional for the new baseline
Roles-and-Access, Eligibility-and-Freshness, Opportunity-Lifecycle, Introduction-and-Consent, Contribution-and-Finance, Events-and-Sessions, Outcomes	Behaviour notes, each citing page numbers and carrying open decisions
Launch-Decisions	The eight p. 20 decisions as GL01 to GL08, plus owner questions N1 to N8 resolved as they are answered. All Pending
Scenarios/ and Gates/	New scenario set (prefix GS) and gates (prefix GA01 to GA12) derived from A1 to A12 and the stated invariants. No oracle is invented; where the Blueprint gives a rule it is quoted
Baseline-README	Revision label, status, how it relates to 1.3, validator notes

New ID prefixes avoid collision with existing immutable IDs: scenarios GS01..., gates GA01...GA12, launch decisions GL01...GL08, new open questions GQ01.... Old IDs are never renumbered or reused.

4.2 Minimal edits to existing evidence (owner-authorised, GGA_VAULT_EVIDENCE_EDIT=1)

Only these, each a pointer, never a rewrite:

1. 00-Start-Here.md: add a section “Superseded in part by revision GGA-1.0 baseline” linking the Supersession Register. Keep the phrases the validator requires.
2. README.txt: one line with the same pointer.
3. 01-Overview/Document-Lineage.md: append rows 8 to 11 for the four new documents. (If the validator constrains this note, use the baseline folder instead and skip this edit.)

No other note in folders 01 to 11 or 99 changes. Old notes keep their content and are marked only through the register.

4.3 Hook change

Extend both copies (bootstrap-kit/protect_vault_evidence.py and .claude/hooks/protect_vault_evidence.py), their tests and .claude/hooks/README.md so 13-* and root README.txt are protected once the baseline is accepted. The hook guards only Claude’s direct Write, Edit and NotebookEdit events; add a CI path-diff check if repository-wide enforcement is wanted.

4.4 Engineering layer 12-Development/ updates

These are mine to change and are rewritten after the baseline notes exist:

Area	Change
Application-Architecture, Data-Architecture, Request-Pipeline, Authentication-and-Authorization, Company-Isolation	Rework around the Blueprint: single application with public, member and operations surfaces; public/member/restricted projections; eligibility derived at request time; grants versus consents; status-code contract (401, 403, 404, 409, 422, 429); idempotency key scoped to actor and action with changed-payload failure
Outbox-and-Worker	Job catalogue (profile reminders, listing expiry, consent follow-up, outcome prompts, event reminders, renewal) and the 1 min, 5 min, 30 min, 2 h then exception-queue retry policy; keep the no-exactly-once rule
Integration-Ports	Add ObjectStorage, FileScanner, optional PaymentProvider, CalendarProvider; keep Identity and Email; AI adapter optional and off by default
Modules	Replace the four modules with: Identity and Company Profile; Eligibility and Freshness; Partners and Opportunities; Introductions and Consent; Events and Sessions; Outcomes and Contribution; Operations Console and Notifications; Files. DG-Manual-Services set to Parked or retired per N2
testing/*	Regenerate inventory, coverage, isolation list, impact matrix and decision gates from the baseline folder. Keep the old inventory as a historical note
ADRs	Review ADR-0001 to ADR-0005 against the Blueprint (see 4.5). Add ADRs for projections, file storage and scanning, configuration register, money (integer minor units, explicit currency), consent and grant records, and payment approach
Gap-and-Risk-Register, Decision-Gates, Environment-Configuration, Build-Test-and-Deployment	Update to the new decisions, targets (24-hour recovery point, 8-hour restoration, 100 companies, 1,000 listings, 25 concurrent users, 95% under 2 seconds) marked as proposed targets
Planning/ISSUE-PLAN.*	Superseded; regenerate from the new baseline after review. PR #4 is already merged (2026-10-20). Its plan is superseded and must not be passed to file_issues.py: add a supersession banner to both artifacts and to TODOS.md, keep the history, regenerate after review.

4.5 Quick check of existing ADRs against the Blueprint

ADR	Verdict
ADR-0001 stack	Compatible. Blueprint says PostgreSQL is a reference choice, not mandatory, and leaves hosting, auth, email, scanning and backups to the developer and GGA (p. 20)
ADR-0002 polling outbox, no Redis	Compatible with p. 11 and p. 16
ADR-0003 row policies	Compatible; add the Blueprint note to test with the real application role because owners bypass row security (p. 17)
ADR-0004 UUIDv7 and idempotency	Extend: key scoped to actor and action; same key with changed payload fails (p. 15)
ADR-0005 CI on every PR	Unaffected

4.6 Repository files

CLAUDE.md, AGENTS.md, SECURITY.md (product description, the non-negotiable rules list, the section 13 checklist: generalise (never remove) the “private message bodies” logging rule to cover restricted payloads, pitches, contact packages, outcome narratives, revenue, personal contacts and document contents; add file scanning, consent, finance separation), TODOS.md, .github/labels.json (a template, not live GitHub: run a reviewed label migration, creating new phase and module labels first, updating templates and skills, keeping legacy labels on merged history), PR and issue templates (scenario ID prefixes), README.md. The canonical operating contract and gga-next-issue skill hard-code T##/DG##, A##/S##, Qnn, Step 11, folders 00 to 11 and 99 and step-NN labels: update the canonical sources, then regenerate adapters with sync_adapters.py.

5. Sequencing

Step	Output	Gate
0	This plan, reviewed by Codex, then by the owner	Owner answers N1 to N8
1	13-GGA-Network-Baseline skeleton: Source-Digest, Requirement-Register, Baseline-README. Sources copied with checksums	Owner reviews register
2	Supersession-Register (generated first pass), behaviour notes, Launch-Decisions	Owner reviews dispositions
3	New scenarios and gates, Scope-Release-One, minimal pointer edits, hook extension	Validator 0 FAIL; owner accepts baseline
4	12-Development rewrite (section 4.4)	Review
5	Repository files (4.6)	Review
6	New issue plan (dry run), owner approval, filing	Owner approval

Each step is its own branch and PR. Steps 1 to 3 touch only 13-*, the three pointer files and the hook.

6. Risks and honesty notes

• The new documents are client feedback and proposals; they are not signed decisions. Proposed defaults stay proposals. No Q or GL decision is marked decided by this plan.
• Review in the Blueprint (p. 2) checks completeness and authority, not truth of claims. The vault must not word it as verification.
• Cross-border data sharing across three jurisdictions, tax treatment of the contribution, and retention are flagged for the named data owner and finance owner. This plan gives no legal or tax advice.
• Revenue figures and personal contacts are restricted data; the baseline must say who may see them (operations, finance scope, p. 3).
• Revision labelling: the existing notes carry vault_revision: "1.3". The baseline needs its own label (proposed: GGA-1.0, after the source version) so the two never blur.
• Unclear in the sources, listed for the client: who may publish listings besides partners (the Idea says participating companies also submit; p. 14 allows partner approval or eligible company status); whether event registration for non-eligible guests exists; language of consent text; retention periods; what “approved tax treatment” is.

7. What I am asking Codex to review

Whether the conflict list is complete and correct against the sources; whether the second-baseline approach is sound given the validator and hook constraints; whether the proposed ID namespaces are safe; whether any Blueprint requirement is missed; and whether the sequencing keeps the owner in control of decisions.

8. Review round 1 (Codex, gpt-5.6-sol, high reasoning, read-only)

Verdict: ISSUES FOUND; 0 Critical, 6 High, 10 Medium, 4 Low. Findings were checked where possible (PR #4 is merged; the validator ignores a GS01.md placed in 06-Scenarios). Dispositions:

#	Finding (short)	Disposition
1	A passing validator would imply the new baseline is validated	Accept: add a baseline validator (4.7); “0 FAIL” must cover legacy and baseline checks
2	Questions assigned to the wrong authority	Accept: see section 9
3	Source precedence and listing-submitter ambiguity	Accept: question N9 (section 9)
4	PR #4 already merged	Applied (4.4)
5	gga-next-issue needs real changes	Applied (4.6)
6	No security acceptance plan	Accept: 4.8
7	Second baseline premature; root navigation misleading	Accept: 13-* is a candidate baseline; with N1 answered (same client) 00-Start-Here.md becomes a neutral router, not a one-line pointer
8	Conflict table incomplete	Accept: C16 to C20 below
9	Blueprint T1 to T3 collide with T01 to T40	Accept: cite only as Blueprint-T1; no bare T1 notes or links
10	Deliverables without destination	Accept: requirement-to-destination matrix (4.7) incl. owner transfer, invitation expiry, OpenAPI with examples, essential-record export, handover package, configuration register, recurring cost, pilot metrics, monthly restore rehearsal, incident communication owner
11	Checksums not covered	Accept: sources under 13-*/Sources/ with a manifest checked by the baseline validator
12	Hook change incomplete	Applied (4.3)
13	N1 to N8 gate different stages	Accept: staged gates (section 9)
14	Removing the log rule weakens protection	Applied (4.6)
15	Label migration underspecified	Applied (4.6)
16	”Fixed commitment” and GGA-1.0 imply approval	Accept: two fields, source_classification and approval_status; label the baseline GGA-Network-Candidate-2026-10-20
17	Citation wording	Applied
18	Empty source metadata	Applied
19	Touch-scope incomplete	Accept: steps 1 to 3 touch 13-* (incl. Sources and manifest), the baseline validator, both hook copies, tests, hook docs and the pointer files
20	Generic note names	Accept: prefix baseline notes GGA- (for example GGA-Outcomes, GGA-Launch-Decisions)

Additional conflicts (from review)

#	Topic	Conflict
C16	Identity disclosure	D04 named-member opportunities versus anonymous public summaries, names only when approved (p. 5)
C17	Expiry	D06 deferred automatic expiry; expiry is mandatory (p. 5)
C18	Jobs and reminders	Digests and overdue reminders were outside Balanced; recurring profile, consent, event, outcome and renewal jobs are first-release (p. 16)
C19	Sessions	Paid manual weekly sessions become a core fortnightly programme gated by data eligibility, not payment (p. 9)
C20	Operations access	Opaque metadata only becomes review queues and restricted workflows with reason-required overrides (p. 3): an access-policy change, not a role rename

4.7 Baseline validator and traceability

A new script, leaving the legacy validator unchanged: GS, GA, GL and GQ sets are complete and unique; GA01 to GA12 exist; every requirement maps to a behaviour note, engineering note, GS or GA test, GL or GQ decision, or a recorded deferment; every Blueprint page is covered; every GS is Not executed; no pending decision is used as an oracle; source bytes and SHA-256 match the manifest.

4.8 Security acceptance work for the new surfaces

Public HTML, JSON, metadata, caches, search, analytics and social previews must not leak gated data; withdrawal invalidates the approved projection (already-public copies cannot be recalled); uploads are quarantined, sniffed and scanned, downloads check grant, version and expiry, storage keys stay secret; finance and operations are separated and settlement or webhook calls are authorised; MFA for privileged staff and logged exceptional technical access; correction, export and deletion across files, indexes and restores; eligibility computed at request time on reads, downloads, exports and background jobs; row policies tested with the real application role.

9. Owner direction received (2026-10-20) and what it changes

Recorded as direction from the repository owner, who is relaying the client’s feedback. It is not a signed client decision on any Q or GL item.

Q	Direction	Effect on the plan
N1	GGA is the actual name. Use GGA instead of DG from now on	Same client and engagement. The earlier “DG” name was a placeholder. All new and rewritten notes, instructions and issues say GGA. Evidence folders 01 to 11 and 99 keep “DG” as history and are mapped in the register (DG = GGA for the same organisation). Scenario IDs DG01 to DG44 and decision IDs D01 to D10 are never renumbered; the register notes that the prefix is historical
N2	Do as the new feedback says; the vault may be outdated	The new documents govern wherever they speak. The DG paid-service track (S01 to S13, DG01 to DG44, Q12 to Q25) is not in the new concept: mark Superseded by the GGA model where the new documents replace it, and Parked, no client feedback where they are silent
N3	Keep as Proposed anything the new documents do not cover (no feedback on that area)	Private questions, discussions, next actions and similar vault features stay as Proposed carry-forwards, labelled “no GGA feedback received”. They do not block the new baseline and must not contradict it. Open direct messaging remains deferred per Blueprint p. 1
N4	Same as N3, and follow the documents	A material edit to a live listing pauses the affected listing until re-approved (Blueprint p. 5). The V1-stays-live rule is superseded for listings; keep immutable approved versions
N5	Same as N3, and follow the documents	Contribution opt-in, finance approval, manual invoicing, bank reconciliation and 12-month terms are in scope (pp. 8, 15, 16). A payment gateway stays optional. Commercial and tax treatment remain finance decisions
N6	Not answered	Treated as “follow the documents”: public summaries and shareable public URLs are intended (pp. 3, 10, 14). Indexing and social-preview policy stays a launch decision
N7	New proposal; groom and improve the delivery plan as was done for 1.3, following the documents	Replace the options-and-schedule notes’ status with a groomed delivery plan built on Blueprint p. 19 (five stages, handover package, pilot metrics). Fees and dates stay open until the client sets them
N8	Help with it	I will draft a roles and ownership worksheet (operations owner and backup, finance approver, data owner, event lead, technical owner, partner onboarding owner) with the decision each must make, to send to GGA. I will not name anyone

New open question N9: source precedence and status. The four documents differ slightly (the Idea lets participating companies submit listings; Blueprint p. 13 lets only approved partners publish, p. 14 allows partner approval or eligible-company status). Proposed rule: the Blueprint wins over the Concept and the Idea where they differ, and each discrepancy is listed for the client. Also confirm whether users may hold more than one company membership.

Staged gates: source ingest and requirement extraction can start now; supersession dispositions and the engineering rewrite need N9; named owners (N8) are needed before launch, not before design.

10. Next step proposal

Step 1 as in section 5, with the naming rule above: branch for 13-GGA-Network-Baseline (candidate baseline) containing GGA-Source-Digest, GGA-Requirement-Register, GGA-Baseline-README, the Sources/ copies with manifest, and the baseline validator. No existing evidence is edited in this step.

11. Revised approach (owner instruction, 2026-10-20): rewrite in place

Instruction: the client feedback in docs/ is on top; every note under Brain/ is altered to the feedback and Blueprint; the vault’s own deep findings that support the Blueprint are kept; no information from either side is ignored. This replaces the “second candidate baseline folder” idea in section 4. Sections 1 to 3, 4.3 to 4.8, 8 and 9 still apply.

Decisions taken:

1. Old content: rewrite in place; retired items stay as short “Superseded by GGA feedback” notes that keep their findings and IDs. Rev 1.3 is preserved as git tag vault-rev-1.3 (commit 4008663).
2. IDs: keep DG01 to DG44 and D01 to D10. All text says GGA. The glossary states the DG prefix is historical and means GGA. New items use new prefixes (GS, GA, GL, GQ; cite Blueprint references as Blueprint-T1 to avoid colliding with T01).
3. Hook: the owner restarts Claude Code with GGA_VAULT_EVIDENCE_EDIT=1. The hook is never bypassed through shell commands.

11.1 Reconciliation method (nothing ignored on either side)

For every vault note, the rewrite records four things in a working matrix (Planning/Rewrite-Matrix, one row per note, then per scenario and decision):

• Old fact(s) in the note (including its review findings).
• GGA feedback that touches it, with Blueprint page.
• Disposition: Retain, Reframe, Replace, Supersede-and-keep, or Proposed carry-forward (no GGA feedback received).
• Result: what the rewritten note now says, and where each retained finding went. Where the feedback and the vault disagree, the feedback governs. Where only the vault speaks, it stays and is marked “Proposed, no GGA feedback received”. Where only the feedback speaks, it is new content, tagged with its source class (fixed commitment, proposed default, launch decision, design proposal) and approval_status.

11.2 Vault findings to carry into the GGA model (support the Blueprint)

• Tests-first method, deferred integration checks, “primary step is an index, not proof”, Passed only on a named integrated build and fixture, manual evidence kept apart (Blueprint A1 to A12 need exactly this discipline).
• Deny-by-default pipeline; indistinguishable denial (T27); three-company canary isolation fixture and race-injection harness (Blueprint A9, A6).
• Transactional outbox, at-least-once with duplicate protection, no exactly-once claim, reconcile ambiguous sends (Blueprint pp. 15 and 16 say the same).
• Exact-version approval binding, stale-write conflict, idempotency bound to actor, command, attempt and payload (Blueprint pp. 5, 6, 15).
• Generic email with an authenticated link that re-authorises; recipient re-checked at send time (Blueprint p. 17).
• Honest status vocabulary; proposed default is never a prerequisite; scope guards that stop silent expansion (DG24, DG44 become the GGA scope guards for deferred items such as AI matching, open messaging, WhatsApp, native apps).
• A11-style documentary coverage disposition for excluded features (Japanese and Korean interface, AI).
• Rule-based ranking with evidence and gaps, unknown is a gap not a contradiction (Blueprint p. 7).
• Review history R01 to R08, F01 to F04 and the exchanges: kept as history with banners; their lessons feed the validator checks.
• Internal effort estimates and milestone proposal: kept as labelled history; Blueprint scope needs re-estimation before any figure is reused.

11.3 Work packages (each its own branch and PR, each independently reviewed)

WP	Scope	Needs
R1	Copy the four sources into 10-Sources/originals with inventory rows; 00-Start-Here, 01-Overview (Status, Scope, Glossary, Lineage); GGA source digest, requirement register, supersession register; baseline validator checks	Hook override
R2	02-Architecture, 03-Journeys, 08-Commercial-and-Schedule (groomed delivery plan on Blueprint p. 19)	R1
R3	07-Decisions: Q01 to Q25 dispositions, D01 to D10, new GL01 to GL08 launch decisions, GQ questions, decision index	R1
R4	06-Scenarios: T01 to T40 and DG01 to DG44 dispositions, new GS scenarios, GA01 to GA12 gates, index, traceability, mixed-evidence	R2, R3
R5	05-Implementation-Order: new build order from Blueprint stages, steps rewritten, dependency table	R4
R6	04-DG-Services (superseded or parked per N2/N3), 09-Exchanges-and-Reviews banners and index, 10-Sources notes	R1
R7	11-Tooling validator rewrite for the new counts and rules, 99-Validation regenerated	R1 to R6
R8	12-Development, CLAUDE.md, AGENTS.md, SECURITY.md, labels, templates, TODOS.md, skill and contract; new issue plan (dry run)	R1 to R7

No GitHub issue or epic is filed until R8 is approved.

11.4 Handoff for the restarted session

1. Branch plan/client-feedback-update holds this plan (local commit; pushed with this change). Tag vault-rev-1.3 is local; push it with git push origin vault-rev-1.3.
2. Restart Claude Code in D:\work\gga with GGA_VAULT_EVIDENCE_EDIT=1 set, then say “continue with R1”.
3. Source extracts for review are in docs/extracted/ (untracked); the originals are in docs/.
4. Read order: this plan, docs/extracted/GGA_Development_Blueprint.txt (20 pages), the Concept and Architecture extract, then the vault notes of the work package.