Add governance docs: Emergent.sh licensing, Vercel integration, and repository roles

LICENSE

@@ -0,0 +1,22 @@
+MIT License
+
+Copyright (c) 2026 Microsoft, VitrixLab, VitrixLab Internship Initiative Program 
+and Jason "Soo Ji" Dano | "Peper Cruz" Et.al
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

README

@@ -0,0 +1,55 @@
+# Repository Roles & Permissions
+
+This document defines the standard access roles used to manage permissions and governance for this repository.
+
+---
+
+## Purpose
+
+Ensure clear ownership, least-privilege access, and auditable contribution paths.
+
+---
+
+## Pre-Defined Roles
+
+### Read
+
+- Read and clone repositories  
+- Open and comment on issues  
+- Open and comment on pull requests  
+
+**Use for:** Viewers, auditors, and observers
+
+---
+
+### Triage
+
+Includes all **Read** permissions, plus:
+
+- Manage issues  
+- Manage pull requests  
+
+**Use for:** QA reviewers, documentation stewards, and maintainers in training
+
+---
+
+### Write
+
+Includes all **Triage** permissions, plus:
+
+- Push to repositories  
+
+**Use for:** Core contributors and maintainers
+
+---
+
+## Governance Principles
+
+- Apply **least privilege** by default  
+- Grant Write access only after governance review  
+- All role changes must be auditable  
+
+---
+
+> Framework Alignment: AIOpsLab, CMARC-2026, AI Safe Engineering  
+> Status: Active

README.md

@@ -473,7 +473,7 @@ This project has adopted the [Microsoft Open Source Code of Conduct](https://ope
 
 ## License
 
-Copyright (c) Microsoft Corporation. All rights reserved.
+Copyright (c) Microsoft Corporation, VitrixLab, VitrixLab Internship Initiative Program and Jason "Soo Ji" Dano | "Peper Cruz" Et.al. All rights reserved.
 
 Licensed under the [MIT](LICENSE.txt) license.
 

sanity-check/BASIC INFRA REQS.md

@@ -0,0 +1,80 @@
+# Super MVP — sc-mvp/cluster-setup
+
+## 1️⃣ Goal
+Spin up a **lightweight, reproducible Kubernetes cluster** using **k3s or kind**, forming the foundation for the SC-MVP pipeline.
+
+---
+
+## 2️⃣ Requirements
+
+| Requirement | Details |
+| ----------- | ------- |
+| **Cluster Type** | k3s (lightweight Kubernetes) or kind (Kubernetes in Docker) |
+| **Nodes** | 1 control-plane + 1 worker node minimum |
+| **Resource Limits** | CPU: 500m, Memory: 512Mi per node |
+| **Namespace Isolation** | Optional namespace `sc-mvp-test` for app deployments |
+| **Tools Required** | Docker, kubectl, kind or k3s CLI |
+| **Reproducibility** | Cluster should be reproducible on any contributor machine |
+
+---
+
+## 3️⃣ Deployment Steps (Kind Example)
+
+1. **Create a kind configuration file**
+
+`kind-config.yaml`:
+
+2. **Create the cluster**
+
+`kind create cluster --name sc-mvp --config kind-config.yaml`
+
+3. **Verify cluster status**
+
+`
+kubectl cluster-info --context kind-sc-mvp
+kubectl get nodes
+`
+
+4. **Opt: Create namespace for testing**
+
+`kubectl create namespace sc-mvp-test`
+
+5. **Check namespace**
+
+`kubectl get ns`
+
+4️⃣ Logging & Verification
+
+1. Capture stdout/stderr of `kind create cluster`.
+
+2. Record `kubectl get nodes` output.
+
+3. Timestamp logs for reproducibility.
+
+4. Ensure nodes are `Ready` before proceeding to app deployment.
+
+5️⃣ Optional Safety Features
+
+1. Delete cluster on failure or cleanup:
+
+2. `kind delete cluster --name sc-mvp`
+
+3. Set resource constraints in Docker for nodes if machine resources are limited.
+
+4. Verify Docker daemon is running before cluster creation.
+
+6️⃣ Deliverables
+
+1. `kind-config.yaml` → Cluster configuration manifest
+
+2. Deployment logs → `sc-mvp-cluster-setup.log`
+
+3. Optional namespace `sc-mvp-test` for app deployment
+
+4. Documentation of steps for reproducibility
+```yaml
+kind: Cluster
+apiVersion: kind.x-k8s.io/v1alpha4
+nodes:
+  - role: control-plane
+  - role: worker

sanity-desk/HOTEL RESERVATION APP MICROSERVICE ARCHITECTURE.md

@@ -0,0 +1,89 @@
+# Super MVP — sc-mvp/app-deploy
+
+## 1️⃣ Goal
+Deploy a **hotel reservation application** onto the SC-MVP Kubernetes cluster and validate that the deployment is **idempotent, observable, and verifiably successful**, forming **Checkpoint SC-MVP-02** in the pipeline.
+
+---
+
+## 2️⃣ Requirements
+
+| Requirement | Details |
+| ----------- | ------- |
+| **Target Cluster** | Existing SC-MVP cluster (from SC-MVP-01) |
+| **Namespace** | `sc-mvp-test` |
+| **Deployment Method** | Declarative Kubernetes manifests |
+| **Idempotency** | Re-applying manifests must not cause errors or drift |
+| **Verification Tools** | kubectl |
+| **Logging Format** | CSV / JSON (SQLite ETL compatible) |
+| **Rollback Strategy** | Automatic or manual rollback on failure |
+
+---
+
+## 3️⃣ Deployment Steps
+
+### 3.1 Application Manifests
+- Kubernetes **Deployment** manifest for the hotel reservation app
+- Kubernetes **Service** manifest for internal/external access
+- Optional **Ingress** manifest (environment-dependent)
+
+---
+
+### 3.2 Apply Deployment
+- Apply manifests to the `sc-mvp-test` namespace
+- Ensure repeated `kubectl apply` operations are safe and consistent
+
+---
+
+### 3.3 Rollout Verification
+- Validate rollout completion using:
+  - `kubectl rollout status`
+  - Pod readiness and availability checks
+- Confirm service endpoint accessibility
+
+---
+
+### 3.4 Idempotency Validation
+- Re-apply manifests
+- Confirm:
+  - No unintended restarts
+  - No configuration drift
+  - Stable pod state
+
+---
+
+## 4️⃣ Logging & Verification
+- Capture stdout/stderr from deployment commands
+- Record:
+  - Deployment timestamps (apply / start / ready)
+  - Pod status and restart counts
+  - Image tag and/or digest used
+- Store logs in **CSV/JSON** format for SQLite ingestion
+- Mark checkpoint as **PASS** only if rollout completes successfully
+
+---
+
+## 5️⃣ Failure Handling & Safety
+- On failure:
+  - Trigger rollback or enter explicit failed state
+  - Preserve cluster state and logs for audit
+- Do not auto-delete resources unless explicitly configured
+
+---
+
+## 6️⃣ Deliverables
+- Application deployment manifests
+- Rollout verification logs (CSV/JSON)
+- Idempotency validation evidence
+- Documentation describing:
+  - Deployment procedure
+  - Verification steps
+  - Re-run behavior and constraints
+
+---
+
+## Checkpoint Summary
+
+**Checkpoint ID:** SC-MVP-02  
+**Branch:** `sc-mvp/app-deploy`  
+**Purpose:** App Deployment & Rollout Verification  
+**Status:** ☐ PASS / ☐ FAIL (to be recorded during execution)

vitrixlab/BASIC INFRA REQs.md

@@ -0,0 +1,80 @@
+# Super MVP — sc-mvp/cluster-setup
+
+## 1️⃣ Goal
+Spin up a **lightweight, reproducible Kubernetes cluster** using **k3s or kind**, forming the foundation for the SC-MVP pipeline.
+
+---
+
+## 2️⃣ Requirements
+
+| Requirement | Details |
+| ----------- | ------- |
+| **Cluster Type** | k3s (lightweight Kubernetes) or kind (Kubernetes in Docker) |
+| **Nodes** | 1 control-plane + 1 worker node minimum |
+| **Resource Limits** | CPU: 500m, Memory: 512Mi per node |
+| **Namespace Isolation** | Optional namespace `sc-mvp-test` for app deployments |
+| **Tools Required** | Docker, kubectl, kind or k3s CLI |
+| **Reproducibility** | Cluster should be reproducible on any contributor machine |
+
+---
+
+## 3️⃣ Deployment Steps (Kind Example)
+
+1. **Create a kind configuration file**
+
+`kind-config.yaml`:
+
+2. **Create the cluster**
+
+`kind create cluster --name sc-mvp --config kind-config.yaml`
+
+3. **Verify cluster status**
+
+`
+kubectl cluster-info --context kind-sc-mvp
+kubectl get nodes
+`
+
+4. **Opt: Create namespace for testing**
+
+`kubectl create namespace sc-mvp-test`
+
+5. **Check namespace**
+
+`kubectl get ns`
+
+4️⃣ Logging & Verification
+
+1. Capture stdout/stderr of `kind create cluster`.
+
+2. Record `kubectl get nodes` output.
+
+3. Timestamp logs for reproducibility.
+
+4. Ensure nodes are `Ready` before proceeding to app deployment.
+
+5️⃣ Optional Safety Features
+
+1. Delete cluster on failure or cleanup:
+
+2. `kind delete cluster --name sc-mvp`
+
+3. Set resource constraints in Docker for nodes if machine resources are limited.
+
+4. Verify Docker daemon is running before cluster creation.
+
+6️⃣ Deliverables
+
+1. `kind-config.yaml` → Cluster configuration manifest
+
+2. Deployment logs → `sc-mvp-cluster-setup.log`
+
+3. Optional namespace `sc-mvp-test` for app deployment
+
+4. Documentation of steps for reproducibility
+```yaml
+kind: Cluster
+apiVersion: kind.x-k8s.io/v1alpha4
+nodes:
+  - role: control-plane
+  - role: worker