chore: 🚀 Initial repository setup and commit

Author: Donald Fountain

.gitignore.example .gitignore.gitignore.example renamed to .gitignore

@@ -1,152 +1,113 @@
-# [PROJECT/AREA/SCOPE NAME] Architecture
+# Architecture
 
-<!-- 
-Purpose: System design, structure, patterns, and key decisions
-Audience: AI agents needing to understand how this is organized/built
-Update Frequency: When architectural patterns emerge or change
--->
-
-## Overview
-
-<!-- High-level architectural summary in 2-3 paragraphs -->
-
-[PROJECT/AREA/SCOPE NAME] is architected as...
-
-<!-- Describe the fundamental structure, organization, or design approach -->
-
-## Core Components
-
-<!-- For projects: technical components. For life areas: organizational areas. For repos: code modules -->
-
-### [Component/Area 1]
-**Purpose:** [What this does]  
-**Location:** [Where this lives - path, directory, section]  
-**Key Characteristics:** [Important details about this component]
-
-### [Component/Area 2]
-**Purpose:** [What this does]  
-**Location:** [Where this lives - path, directory, section]  
-**Key Characteristics:** [Important details about this component]
-
-### [Component/Area 3]
-**Purpose:** [What this does]  
-**Location:** [Where this lives - path, directory, section]  
-**Key Characteristics:** [Important details about this component]
-
-## Structure
-
-<!-- Directory/file structure, organizational hierarchy, or system layout -->
+## Repository Structure
 
 ```
-[project-root]/
-├── [directory-1]/        # [Purpose]
-│   ├── [subdirectory]/   # [Purpose]
-│   └── [file-pattern]    # [Purpose]
-├── [directory-2]/        # [Purpose]
-│   └── [subdirectory]/   # [Purpose]
-└── [directory-3]/        # [Purpose]
+sharepoint-web-part/
+├── assets/                     # Screenshots, repo banner, documentation images
+├── demo-corp-intranet/         # Main SPFx solution (production demo)
+│   ├── src/
+│   │   ├── assets/             # Web part graphics (hero, icons, cards)
+│   │   └── webparts/           # Web part implementations
+│   │       ├── heroBanner/
+│   │       ├── quickLinks/
+│   │       └── featureCards/
+│   ├── config/                 # Build configuration
+│   └── sharepoint/solution/    # Packaged .sppkg output
+├── docs/                       # Documentation and templates
+├── project/                    # Initial Hello World test (archived)
+└── work-logs/                  # Development milestone history
+    └── 01-github-and-project-setup/
 ```
 
-<!-- 
-Adapt this to scope:
-- Projects: File system structure
-- Life areas: Organizational structure (how information/tasks are organized)
-- Repos: Code architecture and module layout
--->
-
-## Design Patterns and Principles
+## Web Part Architecture
 
-<!-- Architectural decisions, design patterns used, principles followed -->
+### Design Pattern: HTML/CSS/JS (No Framework)
 
-### Key Patterns
+**Rationale:**
 
-- **[Pattern 1]:** [Description and rationale]
-- **[Pattern 2]:** [Description and rationale]
-- **[Pattern 3]:** [Description and rationale]
+- Simple for clients to customize
+- No React learning curve
+- Minimal build complexity
+- Property panes provide no-code configuration
 
-<!-- Example: "Event-driven architecture for decoupled component communication" -->
+### Component Structure
 
-### Design Principles
-
-1. **[Principle 1]:** [What and why]
-2. **[Principle 2]:** [What and why]
-3. **[Principle 3]:** [What and why]
-
-<!-- Example: "KISS principle: Prefer simple, terminal-ready solutions over complex frameworks" -->
-
-## Integration Points
-
-<!-- How this connects to other systems, projects, areas, or external services -->
-
-### Internal Integrations
-- **[System/Project/Area]:** [How they connect, what's shared]
-- **[System/Project/Area]:** [How they connect, what's shared]
-
-### External Integrations
-- **[Service/API/Tool]:** [Purpose, authentication, usage patterns]
-- **[Service/API/Tool]:** [Purpose, authentication, usage patterns]
-
-## Data Flow
-
-<!-- How information/data moves through the system -->
+Each web part follows the same pattern:
 
 ```
-[Source] → [Processing/Transformation] → [Destination]
+webpart-name/
+├── WebPartName.ts              # TypeScript main file
+├── WebPartName.module.scss     # Styles
+├── loc/                        # Localization
+│   ├── mystrings.d.ts
+│   └── en-us.js
+└── WebPartName.manifest.json   # Metadata
 ```
 
-<!-- Describe the primary data flows, pipelines, or information movement patterns -->
+### Data Flow
 
-## Architectural Decisions
+1. **Property Pane → Properties Object** - User configures via UI
+2. **Properties → Render Logic** - TypeScript processes configuration
+3. **Render Logic → DOM** - HTML string injection with styles
+4. **Assets → require()** - Images bundled via Webpack
 
-<!-- Record significant architectural decisions with rationale -->
+## Build System
 
-### [Decision 1]: [Title]
-**Date:** YYYY-MM-DD  
-**Decision:** [What was decided]  
-**Rationale:** [Why this decision was made]  
-**Alternatives Considered:** [What else was considered and why rejected]  
-**Implications:** [What this means for the system]
+**Heft-based SPFx v1.22+**
 
-### [Decision 2]: [Title]
-**Date:** YYYY-MM-DD  
-**Decision:** [What was decided]  
-**Rationale:** [Why this decision was made]  
-**Alternatives Considered:** [What else was considered and why rejected]  
-**Implications:** [What this means for the system]
+```
+Source Code (TypeScript + SCSS)
+       ↓
+   Compilation
+       ↓
+JavaScript Bundles + CSS
+       ↓
+   Packaging
+       ↓
+.sppkg (SharePoint Package)
+       ↓
+  App Catalog Deployment
+       ↓
+Available in Web Part Picker
+```
 
-## Constraints and Limitations
+## Deployment Architecture
 
-<!-- Technical, organizational, or resource constraints affecting architecture -->
+```
+Local Development
+    ↓ (heft start)
+Workbench Testing
+    ↓ (heft package-solution --production)
+.sppkg Package
+    ↓ (Upload to App Catalog)
+Tenant-wide Deployment
+    ↓ (Add to SharePoint Page)
+Published Intranet Page
+```
 
-- **[Constraint 1]:** [Description and impact]
-- **[Constraint 2]:** [Description and impact]
-- **[Constraint 3]:** [Description and impact]
+## Configuration Management
 
-<!-- Example: "Token budget requires on-demand file access patterns instead of loading entire vault" -->
+- **Development:** `config/serve.json` (tenant domain)
+- **Build:** `config/package-solution.json` (version, ID)
+- **Dependencies:** `package.json` (npm packages)
+- **TypeScript:** `tsconfig.json` (compilation settings)
 
-## Future Considerations
+## Asset Management
 
-<!-- Planned evolution, scalability considerations, known technical debt -->
+**Two Asset Locations:**
 
-### Planned Improvements
-- [Architectural improvement or refactoring planned]
-- [Architectural improvement or refactoring planned]
+1. **Repository Assets** (`/assets/`) - Documentation images, banner
+2. **Web Part Assets** (`/demo-corp-intranet/src/assets/`) - Graphics used by web parts (bundled in .sppkg)
 
-### Scalability Considerations
-- [How this will scale or evolve]
-- [What might need to change as this grows]
+Assets in `src/assets/` are webpack-bundled and content-hashed for CDN caching.
 
-### Known Technical Debt
-- [Shortcuts taken, areas needing refactoring]
-- [Shortcuts taken, areas needing refactoring]
+## Documentation Architecture
 
-<!--
-SCOPE ADAPTATIONS:
+**Three-Tier Documentation:**
 
-Projects: Technical architecture, system design, code patterns
-Life Areas: Organizational architecture, information structure, workflow patterns
-Repositories: Code architecture, module design, dependency structure
+1. **Hudu (Published)** - Operational procedures for Dev/Ops teams
+2. **Repository** - Technical reference, architecture decisions
+3. **Code Comments** - Inline implementation notes
 
-This file should answer "How is this built/organized?" at a level that guides
-decision-making without requiring constant reference to implementation details.
--->
+Cross-references link all three tiers for comprehensive coverage.