<!--
IndexTitle: Open Questions
IndexDescription: Non-blocking human decisions collected for batch review.
IndexType: Project
IndexStatus: Active
LastEdited: 2026-06-08
-->

# Open Questions

These are non-blocking draft questions and planning decisions for batch human review.

Agents should keep working unless a question blocks the immediate task. Use current draft decisions for planning and content work, then revisit exact wording, packaging, publishing, and proof details when the project owner is ready.

Do not treat rough human answer notes as final public website copy. Convert them into planning direction first, then draft public copy in the relevant content files during a scoped content pass.

## Track Distinction

Future agents should clearly distinguish between these two tracks:

- **Get Established On The Web public website:** The public site for GetEstablishedOnTheWeb.com. It explains the method, offer, proof, helper/start path, and AI-ready repository workflow.
- **User one-page business websites:** Future user-facing outputs created from a user's business plan inputs. These are flexible one-page website drafts that may later fit WordPress, static pages, website builders, or other platforms.

Publishing, website content, platform setup, proof, and one-page website questions should name which track they affect.

## Publishing Owner Decision Packet Answers

The owner answered the publishing decision packet in chat on 2026-05-30.

These answers apply to the **Get Established On The Web public website** only.
They do not choose a final platform, approve build work, approve DNS or hosting
setup, approve analytics, approve contact-form setup, approve launch, or apply
to future user one-page business website outputs.

**Answer summary:**

- Public homepage CTA direction: A. Lead with the confirmed anchor, then ask
  visitors to start guided setup through the Get Established Workspace.
- Helper or start path name: A. Use **Guided Setup**.
- Contact path: A. No direct contact path yet; keep contact decisions open
  until platform and privacy choices are clearer.
- Offer packaging direction: A. Draft-stage guided setup using the AI-ready
  repository, with final packaging still open.
- Publishing priority: A. Beginner friendliness and clear explanation, with
  repository-as-proof as support.
- Proof or credibility assets: A. Use the repository itself as the first proof
  point.
- AI evaluation wording: A. Keep AI evaluations separate from testimonials,
  endorsements, certifications, guarantees, and launch proof.
- Publishing approach comparison: A. Comparison may continue, but it must not
  choose a platform or approve build work yet.
- Platform choice approval: A. No platform is approved yet.
- Domain direction: Custom. Bluehost and `getestablishedontheweb.com` are
  known owner context; do not do domain, DNS, hosting, or launch work yet.
- External services for first version: Custom. WordPress and Contact Form 7
  are known owner context; do not set up WordPress, install plugins, configure
  forms, handle credentials, or approve launch work yet.
- Draft-only page sections: A. Review later and decide whether each becomes
  public copy, planning notes, or excluded content.
- Build and deployment approval: A. No build, deployment, hosting setup, or
  generated website output is approved yet.
- Analytics, privacy, and contact-form approval: A. No analytics, privacy
  tooling, or contact-form setup is approved yet.
- Public launch approval: A. No public launch is approved yet.
- Public website scope: A. These decisions apply only to the Get Established
  On The Web public website.
- Future user one-page business website outputs: A. Keep them separate
  flexible source-content outputs until a specific user's inputs and platform
  needs are known.

**Additional owner note:** Each public website page should have a clear title,
catch phrase or headline, and body. Treat this as a future content-structure
planning requirement, not approval to build or publish the website.

## Phase 4 Platform Decision (2026-06-07)

Owner approved the **publishing platform direction** for the Get Established
On The Web public website. Full record:
[Phase4PublishingPlatformDecision.md](Phase4PublishingPlatformDecision.md).

**Approved:**

- Keep website source content as **Markdown** in `Content/Website/Pages/` — no
  HTML build or live pages in the decision pass.
- **Primary publish stack:** WordPress on Bluehost, **StudioPress Genesis**
  framework, **Altitude** child theme, domain context
  `getestablishedontheweb.com`.
- **GitHub Pages:** Planned later as a harmonized static mirror — see
  [GitHubPagesHarmonyPlan.md](GitHubPagesHarmonyPlan.md). No Pages setup yet.
- **Contact Form 7:** Deferred until first pages are live and privacy reviewed.

**Still not approved:** WordPress/Genesis/Altitude install, DNS, hosting setup,
page migration, plugins (including CF7), analytics, public launch, or repo
dependencies for site generation.

**Decision status:** Platform choice **resolved** for GEOTW public website.
Build, deploy, and launch remain open.

## Primary Offer Direction

**Question:** Should guided setup be confirmed as the first public offer, or should another offer take priority?

**Why it matters:** The primary offer will shape the homepage message, offers page, calls to action, and future content priorities.

**Current default assumption:** Use guided setup as the primary draft offer for the next content pass. Treat templates, AI workflow starter materials, repository review, and workshops as supporting or future offer ideas.

**Human answer summary:** The start path should be well rounded and ready to help with practical next steps. It should include help setting up GitHub, starting a business plan, thinking through platform setup basics, and other useful getting-started support.

**Planning decision:** Guided setup is confirmed for draft direction as the primary offer. Frame it as a guided start using the AI-ready repository, including help with GitHub, business planning, platform setup basics, and first website content. Keep the public wording simple and helpful, but do not use the rough human answer as final website copy.

**Decision status:** Resolved for draft direction. Exact packaging, pricing, delivery model, and final public offer wording remain open.

## Homepage Call To Action

**Question:** What should the public homepage ask visitors to do first: start a guided setup, use a prompt, request help, or study the example repository?

**Why it matters:** The call to action will guide homepage structure and determine whether visitors should read a guide, start a prompt, request help, or explore the repository.

**Current default assumption:** Point visitors toward starting guided setup through the foundation step: use the discovery prompt or setup guide to clarify identity, audience, offer direction, proof, and first pages before choosing a website build approach.

**Human answer summary:** For the Get Established On The Web public website, start with something simple now and improve it later. The homepage should offer a helper/start path for getting established on different platforms, while making clear that the AI-ready repository is the main method.

**Planning decision:** The homepage call to action should point to a simple helper/start path. The CTA should emphasize that the AI-ready repository is the main method for getting established, with practical support for GitHub, business planning, platform setup basics, and first website content. This decision applies to the Get Established On The Web public website, not to a user's one-page business website.

**Confirmed slogan / positioning anchor:** "A prepared foundation for using AI to build your online presence." The owner confirmed this as the remembered key phrase on 2026-05-26.

**Decision status:** Resolved for draft direction, including the slogan / positioning anchor. Exact homepage button text, helper page name, contact path, and future final public launch copy remain open.

## Publishing Approach Timing

**Question:** When should the project choose a website publishing approach?

**Why it matters:** Choosing too early could add unnecessary framework, dependency, hosting, or deployment decisions before the content and repository workflow are ready.

**Current default assumption:** Wait until the criteria and readiness gates in `Plans/PublishingDecisionCriteria.md` are satisfied and the practical checklist in `Plans/PublishingDecisionChecklist.md` confirms readiness. The refined website drafts should be accepted and the project owner should confirm the first public call to action and publishing priorities before any platform is chosen.

**Human answer summary:** Be clear about which website is being discussed: the Get Established On The Web public website or a user's one-page business website.

**Planning decision:** Platform choice for the Get Established On The Web public
website is **approved** (2026-06-07): WordPress + StudioPress Genesis + Altitude
on Bluehost; Markdown remains source; GitHub Pages harmony planned later. User
one-page business websites remain flexible outputs. Build, DNS, hosting, and
launch still require separate approval. See
[Phase4PublishingPlatformDecision.md](Phase4PublishingPlatformDecision.md).

**Decision status:** Resolved for platform direction (2026-06-07). Build,
deployment, domain setup, and launch remain open.

## Proof Or Credibility Assets

**Question:** What proof, examples, history, testimonials, screenshots, or project artifacts should support the public website?

**Why it matters:** Credibility assets will help the site make grounded claims and avoid unsupported hype.

**Current default assumption:** Use the repository itself as the first proof point, then gather more specific examples as the method is tested.

**Human answer summary:** The project owner wants agents from different AI suppliers to rate or evaluate the repository, then publish those results as credibility support.

**Planning decision:** Credibility assets may include repository proof, tutorial demonstrations, screenshots, and AI agent evaluations. Do not call AI evaluations testimonials unless that label is clearly appropriate and the source, context, and limitations are clear. Human customer testimonials, AI evaluations, repository proof, and tutorial demonstrations should remain distinct asset types.

**Decision status:** Resolved for draft credibility direction. Specific AI evaluation prompts, screenshots, tutorial demonstrations, permissions, and final public proof wording remain open.

## Public Origin Story

**Question:** What specific origin story or project-owner context should the About page include?

**Why it matters:** The About page explains why the project exists. A specific origin story would make the page more human and credible without overclaiming.

**Current default assumption:** Keep the About page focused on the project idea and the repository-as-proof until the project owner provides personal or business context.

**Human answer summary:** Work on the personal origin story later. For now, say the site is dedicated to helping small businesses and individuals get established on the web, and explain why the Get Established On The Web method and repository are the way.

**Planning decision:** The origin story can remain mission-first for now. The About page should focus on helping small businesses and individuals get established on the web, explain the value of the Get Established On The Web method, and use the AI-ready repository as proof and process. Do not invent personal history or founder details.

**Decision status:** Resolved for draft direction. Personal origin story details remain open for a later human-provided pass.

## Business Plan Helper Scope

**Question:** How deep should the future Business Plan Helper go: lightweight planning support, a full business plan draft, offer-model guidance, or something else?

**Why it matters:** The scope will determine whether future work creates a simple prompt, a business plan content folder, structured plan drafts, or deeper offer and pricing support.

**Current default assumption:** Keep the Business Plan Helper lightweight and draft-stage. Use it to clarify business identity, audience, offer assumptions, proof, delivery model questions, and next actions without creating pricing, legal, financial, or final business model claims. A quick-path discovery prompt now exists (`Plans/BusinessPlanDiscoveryPrompt.md`) for collecting the nine essential one-page website inputs conversationally. Deeper scope decisions, such as a business plan content folder, additional planning prompts, and offer-model guidance, remain open.

**Human answer summary:** Keep the current lightweight assumption, get it started, and let it grow stronger over time. Add strong organizational guidelines for future content. Avoid making it a stale informational database. Provide curated pointers to the best sources so agents do not have to rediscover them. Prepare for a growing repository with possible future folders and fast, strong indexing.

**Planning decision:** The Business Plan Helper should start lightweight and grow over time. It should avoid becoming an informational database. Future planning should favor curated reference pointers, source lists, strong indexing, clear organization, and documented folder patterns that can be created when real user content needs them. It should help agents find trusted directions quickly without inventing business facts or creating stale source material.

**Decision status:** Resolved for draft scope. Creating reference source files, business plan content files, indexing automation, or new folders remains open and should wait for a scoped future task.

## One-Page Website Workflow Direction

**Question:** How should the one-page business website workflow be framed for users?

**Why it matters:** The one-page workflow connects business planning to a visible first website output. It should be useful without inventing business claims, choosing a platform, or confusing user websites with the Get Established On The Web public website.

**Current default assumption:** The workflow waits for the project owner or a future user to provide real business inputs. No draft will be created by inventing business facts. When ready, start with `Plans/BusinessPlanDiscoveryPrompt.md` to collect inputs, then use `Plans/OnePageWebsiteDraftPrompt.md` to create the draft.

**Human answer summary:** Users should understand that an agent can help quickly draft a flexible business plan, then use that plan to create a flexible one-page website draft. The workflow can also support future help building pages on WordPress and other platforms. Emphasize that a business plan matters for success and is now easier to draft with the repository.

**Planning decision:** The one-page website workflow should help users quickly draft a malleable business plan first, then use that planning foundation to create a malleable one-page website draft. The website draft is a user output, not the Get Established On The Web public website. Later platform help, including WordPress or other website platforms, can be discussed after the business plan and one-page content are clear.

**Decision status:** Resolved for draft workflow direction. Actual business inputs, a first one-page website draft, platform-specific page building, and user-specific publishing decisions remain open.

## Remaining Open Human Decisions

These decisions are still open because they require final human choice or real user/business facts:

- Exact homepage button text, helper page name, contact path, and future final public launch copy for Get Established On The Web.
- Final offer packaging, pricing, delivery model, and service/template/workshop framing.
- Publishing platform, hosting, domain, deployment, analytics, contact, and privacy choices for the Get Established On The Web public website.
- Platform choices for any specific user one-page business website.
- Specific credibility assets, AI evaluation process, screenshots, tutorial demonstrations, permissions, and public proof wording.
- Personal origin story details, if the project owner wants them public later.
- Timing and source inputs for any actual business plan content file or one-page website draft.
- Future reference pointer structure, folder creation, and indexing approach for the Business Plan Helper.

## Environment-Adaptive Operating Model (ENV)

Non-blocking questions from
[CloudOnlyPlanningAndMeasurementDevicePlan.md](CloudOnlyPlanningAndMeasurementDevicePlan.md)
harmonization. Formal terms:
[NamingStandard.md](../Standards/NamingStandard.md) §Environment-Adaptive Model.
Agents should keep working unless a question blocks the immediate task.

**ENV-1: Operating profile persistence** — ✅ **Resolved 2026-06-09**

- **Question:** Where should operating profile and environment snapshot persist?
  Options: `Workspace/OwnerEnvironment.md` (durable register), chat-only per
  session, or both.
- **Decision:** **Both** — `Workspace/OwnerEnvironment.md` is the durable
  register; chat reads and updates it. Do not rely on session memory alone.
- **Source:** Cloud-first harmonization Pass 1
- **Blocking:** Not Blocking

**ENV-2: Environment interview timing** — ✅ **Resolved 2026-06-09**

- **Question:** Is the environment interview mandatory at first Quick Startup,
  or triggered only when local-only instructions would misfire?
- **Decision:** **Triggered** — run the short interview when device or
  environment is unknown, or when local-only instructions would misfire.
  **Local-primary** with known setup uses standard Quick Startup
  (`FirstRunStreamline` path). During profile-aware startup, **offer optional
  uploads** (screenshots, logos, existing copy, prior material) if the user has
  something to share — see
  [EnvironmentDetectionQuestions.md](../Capabilities/SituationalAwareness/EnvironmentDetectionQuestions.md)
  §Optional Uploads.
- **Source:** Cloud-first harmonization Pass 1
- **Blocking:** Not Blocking

**ENV-3: GitHub-primary source of truth** — ✅ **Resolved 2026-06-09**

- **Question:** Confirm GitHub as the working collaboration surface until the
  first local clone for remote-only and GitHub-then-local profiles.
- **Decision:** **Confirmed** — GitHub is the working collaboration surface
  until first local clone for Remote-only and GitHub-then-local profiles; local
  Git becomes authoritative after clone per
  [SourceOfTruthAndMirrorStandard.md](../Standards/SourceOfTruthAndMirrorStandard.md).
- **Source:** [SourceOfTruthAndMirrorStandard.md](../Standards/SourceOfTruthAndMirrorStandard.md)
  §When No Local Clone Exists
- **Blocking:** Not Blocking

**ENV-4: Hosted-agent platform priority** — ✅ **Resolved 2026-06-09**

- **Question:** Which hosted-agent platforms to document first for private-repo
  PR workflow? Candidates: GitHub web, GitHub Copilot Workspace, Cursor Cloud,
  other hosted agents.
- **Decision:** **Tier 1:** GitHub web (PR review, merge) and **Cursor Cloud**
  (hosted-agent implementation). **Tier 2 (defer):** GitHub Copilot Workspace
  until owner uses it. **Tier 3:** generic other hosted agents.
- **Source:** Environment-adaptive harmonization Pass 1
- **Blocking:** Not Blocking

**ENV-5: Cross-platform file consolidation**

- **Question:** Should `Standards/CrossPlatformRepositoryPaths.md` absorb
  `Plans/CrossPlatformCompatibilityNotes.md`, or remain sibling files?
- **Source:** Cloud-first harmonization Pass 2
- **Timing:** Later
- **Blocking:** Not Blocking
- **Notes:** CrossPlatformRepositoryPaths.md created as Draft standard
  2026-06-08.

**ENV-6: Success measurement register**

- **Question:** Extend `Workspace/OwnerGoals.md` with milestone columns, or use
  a separate `Workspace/OwnerMilestones.md` for measurable outcomes?
- **Source:** Cloud-first harmonization Pass 1 §Success Metrics
- **Timing:** Before success template implementation
- **Blocking:** Not Blocking

**ENV-7: Private repository default in packaging**

- **Question:** Should StarterRepositoryPackage document private GitHub
  repository as the default starting point in GettingStarted?
- **Source:** Cloud-first harmonization Pass 1 §Private Repository Default
- **Timing:** Before StarterRepositoryPackage next packaging pass
- **Blocking:** Not Blocking

## OneDriveLink Planning Decisions

These questions are non-blocking. The current default is to keep OneDriveLink
planning-only, use OneDrive's normal sync tools, and keep GitHub as the source
of truth for repository files.

- Which Microsoft account or tenant owns the OneDrive workspace?
- Should the default cloud folder be named `GetEstablishedOnTheWeb`?
- Which computer is the first trusted local sync target?
- Should any OneDrive folders stay cloud-only instead of locally synced?
- What retention rules should apply to scans and private business documents?
- Which phone capture app should be recommended first for scans?
- What repeated manual step would justify future Microsoft Graph work?

## Capability Architecture Questions

These questions are non-blocking and should be revisited when the Capability
system gets its next standards pass.

- See `Plans/GoalsIdeasPlansCapabilitiesModel.md` for the current
  planning model that relates Repository Goals, Ideas, Plans, and Capabilities.
- Resolved 2026-05-28: **CapabilityDefinition** stays in the registry but is
  labeled a **Meta** Capability (alongside CapabilityCreate) so it is not
  mistaken for an operational one. See `Capabilities/README.md`.
- Resolved 2026-05-28: A short write-access-awareness line was promoted into
  `AGENTS.md`; detailed checks remain in CapabilityDefinition and
  CapabilityCreate.
- Resolved 2026-05-28: Planning agents now record an `Environment verified`
  line (repository, branch, write permission) via
  `Plans/PlannerWorkerTaskBriefPrompt.md`.
- Resolved 2026-05-28: A **Data boundaries** section is now conditionally
  required for Capabilities that touch owner information, content, inboxes, or
  external systems. See `Standards/RepositoryCoreStandard.md`.
- Resolved 2026-05-28: **Repository Goals**, **Ideas**, **Plans**, and
  **Capabilities** are now named as formal terms in
  `Standards/NamingStandard.md` (Core Planning Terms), with
  `Plans/GoalsIdeasPlansCapabilitiesModel.md` and the source files as
  their definitions.
- Resolved 2026-05-28: Repository Goals now have a dedicated source-of-truth
  file at `Plans/RepositoryGoals.md`. Supporting context remains in
  `IdentityAndMission.md`, `PrimeExamplePlan.md`, and `Roadmap.md`.

## Skills Integration

These questions arise from the additive Skills proposal. Background and the
recommended architecture are in
[SkillsAndCapabilitiesModel.md](SkillsAndCapabilitiesModel.md) and
[SkillsFolderStructureProposal.md](SkillsFolderStructureProposal.md). Skills are
proposed as an optional, Capability-owned executable layer; Capabilities stay
the primary concept and nothing is renamed.

The owner answered
[SkillsIntegrationDecisionPacket.md](SkillsIntegrationDecisionPacket.md) on
2026-05-30 and selected the recommended option for all four decisions.

**Human answer summary:**

- Discovery surface: keep canonical Skill content under each owning Capability
  and add `Capabilities/SkillRegistry.md` first.
- Pilot Skill: use `Indexing / IndexRefresh` as the first pilot Skill.
- Commissioned repositories: prove the parent pilot first, then adopt into
  commissioned repositories through **CapabilityHarmonize**.
- Phase 2 wiring: approve standards, metadata, naming, registry, and discovery
  updates before any pilot Skill scaffold.

**Planning decision:** Phase 2 wiring is complete. The relevant standards and
discovery files now describe the Capability-owned Skill model, and
`Capabilities/SkillRegistry.md` exists as the flat discovery surface. The
initial `IndexRefresh` Skill scaffold and review are complete. The owner paused
further Skills Integration work on 2026-05-30 and returned the backlog to
broader publishing planning.

**Decision status:** Resolved for Phase 2 wiring and the initial `IndexRefresh`
pilot Skill scaffold/review. Runtime adapter setup, scripts, automation,
generated indexes, actually running Indexing Setup, and any index refresh
remain future tasks that require explicit owner approval.

---

## Clean-Root Migration Owner Decisions

These questions emerged from the migration cleanup and polish passes in
May–June 2026. They supplement the website-and-product decisions above.

For each question, **Timing** is one of: `Now`, `Later`, or
`After Migration Confidence`. **Blocking** is one of: `Blocking`,
`Not Blocking`, or `Advisory`.

---

### Intake Retention Decisions

**Policy adopted 2026-06-07** — see
[IntakeRetentionExecutionReport.md](IntakeRetentionExecutionReport.md) and
updated [Intake/README.md](../Intake/README.md). Intake is **kept**; no deletion
in this pass.

**IND-1: Migration confidence declaration** — ✅ **Adopted 2026-06-07**

- **Decision:** Keep Intake per retention policy until owner explicitly declares
  migration confidence sufficient to **begin deletion planning** (separate
  approved plan). No schedule or deadline.
- **Source:** `Plans/IntakeRetentionPolicyPlan.md` section 4, 8
- **Blocking:** Not Blocking for current work

---

**IND-2: Intake/Owner/ review before deletion** — ✅ **Resolved 2026-06-07**

- **Resolution:** Reviewed `Intake/GetEstablishedOnTheWeb/Owner/`. Only README
  scaffolds in `Notes/`, `OpenQuestions/`, and `Intake/` subfolders — no private
  notes or decisions to migrate to `Workspace/`.
- **Blocking:** Cleared for future deletion planning gate (subject to IND-3)

---

**IND-3: Preserve .git history before deletion**

- **Question:** Should the old git history inside
  `Intake/GetEstablishedOnTheWeb/.git/` be exported or preserved before
  Intake deletion?
- **Source:** `Plans/IntakeRetentionPolicyPlan.md` section 10
- **Timing:** After Migration Confidence
- **Blocking:** Blocking (for Intake deletion approval only)
- **Notes:** Once deleted, the old repository git history cannot be
  recovered. Owner should decide whether migration decisions traced in
  git history are still needed.

---

**IND-4: Intake scaffold folders** — ✅ **Revised 2026-06-07**

- **Decision:** **Do not pre-create** Intake subfolders on the host. Create
  `LargeFiles/`, `RawUploads/`, `Scans/`, or `ToClassify/` only when the first
  file needs that bucket. See [LazyScaffoldHostTighteningReport.md](LazyScaffoldHostTighteningReport.md).
- **Supersedes:** Keep-all-scaffolds decision from Intake retention execution
  (same day).

---

**IND-5: Dropbox selective sync for Intake** — ✅ **Resolved 2026-06-07**

- **Decision:** **Do not exclude** Intake from Dropbox selective sync yet.
  Revisit if sync performance or Cursor indexing noise becomes a problem.
- **Source:** `Plans/IntakeRetentionPolicyPlan.md` section 5

---

### Scaffold And Folder Role Decisions

**SFD-1: Reference folder role** — ✅ Resolved 2026-06-02

- **Question:** What is the active role of the `Reference/` folder?
- **Resolution:** `Reference/` is kept as a lightweight active folder for
  stable external reference notes, source citations, and examples that do
  not belong in `Intake/`, `Plans/`, `Standards/`, or `Capabilities/`.
  `Reference/README.md` was updated with a clear policy including what
  belongs, what does not, and the flat-folder convention. Three empty
  subfolders were removed (see SFD-2).

---

**SFD-2: Reference empty subfolders** — ✅ Resolved 2026-06-02

- **Question:** Should `Reference/Examples/`, `Reference/ExternalDocs/`,
  and `Reference/Setup/` be kept, populated, or removed?
- **Resolution:** All three empty subfolders and their `.gitkeep` files
  were removed. `Reference/` is now flat with only `README.md` until real
  content needs organization.

---

**SFD-3: SharedWorkflow future** — ✅ Resolved 2026-06-02

- **Question:** What should happen to `Capabilities/SharedWorkflow/`?
- **Resolution:** `SharedWorkflow` folder (empty, only `.gitkeep`) was
  removed. Registry row was removed from `Capabilities/README.md`.
  `SharedWorkflow` entry was removed from `AGENTS.md` Capability Discovery
  list. `AssistedAgenticWorkflow` was added to the `AGENTS.md` list in its
  place. `AssistedAgenticWorkflow` already covers the practical supervised
  workflow need.

---

### Capability And Workflow Ownership Decisions

**CAP-1: AssistedAgenticWorkflowCapturePlan.md retention**

- **Question:** Should `Plans/AssistedAgenticWorkflowCapturePlan.md` remain
  in `Plans/` as a superseded historical planning record, or move to
  `Archive/` in a later cleanup pass?
- **Source:** `Plans/AssistedAgenticWorkflowCapturePlan.md` (IndexStatus:
  Superseded)
- **Timing:** Later
- **Blocking:** Not Blocking
- **Notes:** The Capability it planned has been created. The file is now a
  historical record. Moving to `Archive/` would keep Plans/ focused on
  active work. No action needed now.

---

**CAP-2: AssistedAgenticWorkflow Structure.md**

- **Question:** Should a `Structure.md` be added to
  `Capabilities/AssistedAgenticWorkflow/` after a few more passes
  establish which folders the workflow most commonly touches?
- **Source:** `Plans/AssistedAgenticWorkflowCapturePlan.md` section 11,
  `Capabilities/AssistedAgenticWorkflow/README.md`
- **Timing:** Later
- **Blocking:** Not Blocking
- **Notes:** Version 1 has no provisioned folders, so no `Structure.md`
  was created. If common patterns emerge (e.g., which Capability files
  are typically read first in a pass), a short `Structure.md` would
  help orient future agents.

---

**CAP-3: SituationalAwareness core group and per-Capability component** — ✅ **Resolved 2026-06-03**

- **Decision:** Created two-part SA model: core group at
  `Capabilities/SituationalAwareness/` (README, Rules, Prompt) read alongside
  `AGENTS.md`; per-Capability **Situational Awareness** sections in each active
  Capability's `Rules.md` (RepositorySpawn in README).
- **Source:** `Archive/SupersededPlans/SituationalAwarenessCapabilityPlan.md`
- **Notes:** AssistedAgenticWorkflow Rules Section 7 now references core SA.
  Instruction optimization lessons consolidated in SituationalAwareness Rules §6.

---

### Future Triage Decisions

**FTD-1: Plans prompt files triage** — 📋 Triaged 2026-06-02, not yet implemented

- **Question:** Should the preserved prompt files currently parked in
  `Plans/` be triaged into `Capabilities/`, `Standards/`, Content workflow
  guidance, `Archive/`, or a future Skills model?
- **Source:** `Archive/MigrationReports/CleanRootVerificationAndCleanupPlan.md` section 5
- **Triage report:** `Plans/PromptFileTriageReport.md`
- **Timing:** Implement in separate scoped passes (see report Sections 9 A–C)
- **Blocking:** Not Blocking
- **Status:** 45 files inventoried and classified. High-confidence moves
  identified (7 files). Medium-confidence moves identified (9 files).
  Archive batch identified (24 files). Remaining files keep in Plans.
  No files were moved in the triage pass. Implementation requires owner
  approval per bucket (see `Plans/PromptFileTriageReport.md` Section 9).

  **All high-confidence moves completed 2026-06-02:**
  - ✅ `TemplateGuidance.md` → `Standards/TemplateGuidance.md`
  - ✅ `RepositoryArchetypeModel.md` → `Standards/RepositoryArchetypeModel.md`
  - ✅ `CloudToLocalWorkerWorkflow.md` → `Archive/DeprecatedWorkflows/`
  - ✅ `GoogleDriveLinkHumanSetupDecisionPrompt.md` → `Capabilities/GoogleDriveLink/`
  - ✅ `WebsiteContentReadinessReviewPrompt.md` → `Capabilities/ContentReview/`
  - ✅ `PublishingReadinessReviewPrompt.md` → `Capabilities/ContentReview/`
  - ✅ `RepositoryStructureReviewPrompt.md` → `Capabilities/CapabilityAudit/`
  - ✅ `BeginnerUsabilityReviewPrompt.md` → `Capabilities/GettingStarted/`

  **AssistedAgenticWorkflow group completed 2026-06-02:**
  - ✅ `AgentSelfDirectedLoop.md` → `Capabilities/AssistedAgenticWorkflow/`
  - ✅ `PlannerWorkerTaskBriefPrompt.md` → `Capabilities/AssistedAgenticWorkflow/`
  - ✅ `PlannerWorkerWorkflow.md` → `Capabilities/AssistedAgenticWorkflow/`

  **Duplicate resolution completed 2026-06-03:** The 11 high-confidence
  and AssistedAgenticWorkflow promotions above were originally copied,
  leaving stale duplicates in `Plans/`. Those superseded `Plans/` copies
  have now been removed so each workflow has a single canonical home, and
  inbound links were repaired. See
  `Archive/MigrationReports/MigrationCleanupStatusReport.md`.

  **Resolved 2026-06-03 (owner-approved Pass B + Pass C):**
  - GettingStarted discovery group promoted to
    `Capabilities/GettingStarted/`: `BusinessPlanDiscoveryPrompt.md`,
    `OwnerDecisionInterviewPrompt.md`.
  - `WorkflowClarityReviewPrompt.md` promoted to
    `Capabilities/AssistedAgenticWorkflow/`.
  - `WebPresenceQualityReviewPrompt.md` promoted to
    `Capabilities/ContentReview/`.
  - The 21 `*PromptReview.md` context documents were archived to
    `Archive/HistoricalReviews/`.

  **Resolved 2026-06-03 (Content workflow):**
  - `OnePageWebsiteDraftPrompt.md` promoted to
    `Capabilities/OnePageWebsite/OnePageWebsiteDraftPrompt.md` as the initial
    **OnePageWebsite** Capability.
  - `AgentStartWebsiteContent.md` archived to
    `Archive/LegacyDocs/AgentStartWebsiteContent.md` — superseded by existing
    public-site drafts under `Content/Website/Pages/`.

  **Resolved 2026-06-03 (CrossRepoCapabilityGapMatrix task):**
  - Matrix archived to `Archive/SupersededPlans/`; tier model is authoritative in `Standards/RepositoryArchetypeAndCapabilityTiers.md`.
  - Worker prompts archived to `Archive/HistoricalReviews/`.

  FTD-1 is fully resolved. Migration reports archived 2026-06-03 to
  `Archive/MigrationReports/`. See `Plans/MigrationCompleteStatus.md`.

---

**FTD-2: Skills scaffold decision**

- **Question:** Should the `Skills/` scaffold (with three empty subfolders:
  `Definitions/`, `Experimental/`, `SkillCapabilityMap/`) remain as a
  long-term placeholder, be developed into an active Skills layer, or be
  removed?
- **Source:** `Archive/MigrationReports/CleanRootVerificationAndCleanupPlan.md` section 9,
  prior Skills integration work
- **Timing:** Later
- **Blocking:** Not Blocking
- **Notes:** A `Skills/` folder scaffold was created but no Skills migration
  was approved. The initial `IndexRefresh` Skill is owned by the `Indexing`
  Capability. The broader Skills-as-layer question was paused on 2026-05-30.
  The scaffold `.gitkeep` files were kept in the cleanup pass because the
  decision was still open.
