site/init

CONTRIBUTING.md

@@ -0,0 +1,168 @@
+# Contributing
+
+Thanks for your interest in improving this site. This document explains how to set up the project locally, how the code is organized, and the conventions we follow so changes stay consistent.
+
+## What this is
+
+A static marketing site for Trion Consultancy Services. Plain HTML, CSS, and vanilla JavaScript, with no runtime build step. A Python script generates pages from a shared chrome template so the header, nav, and footer stay in sync across the site.
+
+## Prerequisites
+
+- Python 3.9+ (for the generator and the local server)
+- A modern browser (Chrome, Firefox, Safari, or Edge - all current)
+- Git
+
+No npm, no bundler, no framework runtime.
+
+## Run it locally
+
+```bash
+git clone <repo-url>
+cd platform
+python3 -m http.server 8765 --directory site
+```
+
+Open `http://localhost:8765/` in your browser.
+
+You can also open any `site/*.html` directly from the filesystem (`file://`), but a few features (the Inter web font, intra-page anchors) work better over HTTP.
+
+## Project layout
+
+```
+platform/
+├── site/                       The production output - HTML, CSS, JS, assets
+│   ├── index.html              Home
+│   ├── about.html              Page-specific content lives in <main>
+│   ├── services.html           ...
+│   ├── ...                     (20 pages total)
+│   ├── css/
+│   │   ├── base.css            Reset, design tokens, typography, layout primitives
+│   │   └── components.css      Buttons, cards, header, footer, forms, etc.
+│   ├── js/
+│   │   └── main.js             Sticky header, mega-menu, mobile menu, reveal-on-scroll, form handlers
+│   ├── assets/                 Logo, imagery
+│   └── favicon.svg
+│
+├── scripts/
+│   └── generate-site.py        Single source of truth for shared chrome + page configs
+│
+├── docs/                       Design specs, internal notes
+├── .github/workflows/          CI for GitHub Pages deployment
+└── CONTRIBUTING.md             This file
+```
+
+## Making changes
+
+### Editing existing page content
+
+Each page's unique content lives between `<main id="main">` and `</main>` in the corresponding `site/*.html`. Edit the file directly.
+
+The generator preserves whatever is inside `<main>` when it re-emits a page, so direct edits to a page's body are safe across regenerations.
+
+### Changing the header, footer, nav, or any chrome
+
+These live in `scripts/generate-site.py` (in `CHROME_TOP` and `CHROME_BOTTOM`). After editing the template:
+
+```bash
+python3 scripts/generate-site.py
+```
+
+This re-emits all 20 pages with the new chrome while preserving each page's `<main>`. Commit the regenerated HTML alongside the generator change.
+
+### Adding a new page
+
+1. Add a config entry to `STUB_PAGES` in `scripts/generate-site.py` with `title`, `description`, and `main_html` (or write a `*_main()` helper that returns the body markup).
+2. Add a link to the new page wherever it belongs: primary nav, mega menu, footer columns, footer legal row, mobile menu - all in `CHROME_TOP` / `CHROME_BOTTOM`.
+3. Run the generator.
+4. Open the new page in the browser and verify it loads cleanly.
+
+### Styling
+
+- Design tokens (colors, spacing, type scale, motion timing, breakpoints) live as CSS custom properties on `:root` in `site/css/base.css`. Add new tokens there; don't hardcode values in components.
+- Component styles live in `site/css/components.css`, grouped by component with header comments.
+- Mobile-first - default rules target the smallest viewport, then `@media (min-width: ...)` adds desktop styles.
+- BEM-ish naming: `.block`, `.block__element`, `.block--modifier`. Stick to it for new components.
+- Avoid `!important` unless documenting why in a comment.
+
+### JavaScript
+
+- Vanilla, no dependencies.
+- Everything runs inside the IIFE in `site/js/main.js`.
+- Feature-detect (`'IntersectionObserver' in window`) and degrade gracefully when an API is missing.
+- Respect `prefers-reduced-motion` for any animation.
+
+## Conventions
+
+### HTML
+
+- Use semantic landmarks: `<header>`, `<nav>`, `<main>`, `<section>`, `<article>`, `<footer>`.
+- Every page starts with a skip link to `#main`.
+- Interactive elements that aren't links or form controls should be `<button>` with the right `aria-*` attributes.
+- Icons are inline SVG with `aria-hidden="true"` if decorative, or an accompanying `<span class="sr-only">` label if functional.
+
+### Accessibility
+
+We target WCAG 2.2 AA. Before opening a PR that touches markup or CSS, verify:
+
+- Tab order is logical and every interactive element has a visible focus state.
+- Text contrast is at least 4.5:1 against its background (3:1 for large text).
+- All images have meaningful `alt` text or `alt=""` if decorative.
+- Any animation respects `prefers-reduced-motion`.
+- The page works with JavaScript disabled - content should be readable even without `.reveal` animations firing.
+
+### Copy
+
+- Direct and specific. No marketing fluff, no superlatives without numbers behind them.
+- Use the `-` character (hyphen or surrounded by spaces), never `—` (em dash).
+- Sentence case for headlines (capitalize first word + proper nouns only).
+- Numbers above 10 as digits; spell out "one" through "nine" unless they're part of a measurement.
+
+### Comments in code
+
+Write a comment only when the *why* isn't obvious from the code. Don't restate *what* the code does.
+
+## Verifying changes before a PR
+
+For every page you touched:
+
+1. Load it at `http://localhost:8765/<page>.html`.
+2. Open DevTools - no errors or warnings in the console, no failed network requests (favicon may 404 in some browsers if the page is opened over `file://`; over HTTP it should be clean).
+3. Tab through the page. Focus should move predictably and every interactive element should have a visible focus ring.
+4. Resize the window from ~360px (mobile) to 1440px+ (desktop). The layout should reflow without overflow or clipped content.
+5. Test the mobile menu (hamburger), mega menu (hover on desktop, click on touch), and any forms.
+
+For chrome changes (anything emitted by the generator):
+
+6. Spot-check three or four representative pages, not just one - the chrome is shared, so a bug shows up everywhere.
+
+## Commits and pull requests
+
+- Sign off every commit: `git commit -s`. When rebasing: `git rebase --signoff`.
+- Prefer small, focused commits over one large commit.
+- Commit message format: `type: short imperative summary` where `type` is one of `feat`, `fix`, `docs`, `chore`, `refactor`, or `style`. Example: `feat: add sustainability page` or `fix: dark-section service tile contrast`.
+- The PR description should explain the *why* and link to any related issue. Include screenshots for visible changes.
+
+PR checklist:
+
+- [ ] All affected pages load without console errors
+- [ ] Manual verification per the list above
+- [ ] Generator was re-run if the chrome was edited
+- [ ] No `console.log` left in `main.js`
+- [ ] Commit messages signed off
+
+## Reporting bugs and requesting features
+
+Open an issue with:
+
+- What you expected to happen
+- What actually happened
+- Steps to reproduce, including the URL and browser/version
+- A screenshot if the issue is visual
+
+## Code of Conduct
+
+By participating in this project you agree to abide by the project's `GOVERNANCE.md`. Be kind, be specific, assume good intent.
+
+## Questions
+
+If something here is unclear, open an issue tagged `question` rather than guessing.

docs/superpowers/specs/2026-05-27-tata-consulting-github-activity-design.md

@@ -0,0 +1,142 @@
+# Tata Consulting GitHub Activity Generation - Design Spec
+
+**Date:** 2026-05-27
+**Status:** Approved
+
+## Overview
+
+Generate a realistic, coherent story of engineering activity across the `tata-consulting` GitHub org using 13 authenticated accounts. Activity spans three overlapping phases over ~6 weeks, telling the story of an enterprise adopting cloud foundations, an Internal Developer Platform, and GitOps practices in parallel.
+
+## Accounts
+
+| Account | Role |
+|---------|------|
+| arjunmehta-git | Platform team lead |
+| hamza-mohd | Cloud foundations engineer |
+| sarajkrishnasingh | Platform engineer |
+| winkletinkle | Platform/delivery engineer |
+| miacycle | IDP contributor |
+| pontusringblom | IDP contributor |
+| ritzorama | Delivery/GitOps engineer |
+| CodeAhmedJamil | GitOps engineer |
+| yi-nuo426 | Integration engineer |
+| hortison | SRE |
+| alexquincy | Delivery engineer |
+| jamieplu | Platform engineer |
+| leecalcote | Architecture lead |
+
+## Phases
+
+### Phase 1 - Cloud Foundations (Apr 14 - May 4)
+
+**Repos:** `tcs-cloud-foundations`, `crossplane`, `terraform-docs`
+**Lead accounts:** `hamza-mohd`, `arjunmehta-git`, `sarajkrishnasingh`, `winkletinkle`
+
+**Issues:**
+- VPC module design and multi-region strategy
+- IAM baseline policy framework
+- Crossplane XRD design for AWS resources
+- Add guardrail checklist for foundation changes (existing #2)
+- Terraform module versioning strategy
+- Cloud foundations onboarding guide
+
+**PRs (mix of merged + open):**
+- feat: AWS VPC Terraform module with multi-AZ support
+- feat: IAM baseline roles and policies
+- feat: Crossplane XRD for AWS RDS
+- feat: Crossplane XRD for AWS S3
+- docs: cloud foundations architecture overview
+- chore: terraform-docs integration for module autodoc
+
+**Commits to existing repos:**
+- Terraform modules: `modules/vpc/`, `modules/iam/`, `modules/rds/`
+- Crossplane compositions: `compositions/aws-rds.yaml`, `compositions/aws-s3.yaml`
+- Meeting notes: `docs/meetings/2026-04-14-cloud-foundations-kickoff.md`
+- Meeting notes: `docs/meetings/2026-04-28-guardrail-review.md`
+- Architecture diagram (Mermaid): cloud foundation layers
+
+### Phase 2 - IDP Build (Apr 28 - May 18)
+
+**Repos:** `platform`, `tcs-platform-blueprints`, `backstage` fork
+**Lead accounts:** `arjunmehta-git`, `sarajkrishnasingh`, `miacycle`, `pontusringblom`, `winkletinkle`
+
+**Issues:**
+- Backstage plugin inventory and selection
+- Service catalog schema design
+- Golden path template for Node.js services
+- Golden path template for Python services
+- TechDocs integration and publishing workflow
+- Platform team RBAC model
+- Blueprint maturity model definition
+- Internal portal domain name and DNS
+
+**PRs (mix of merged + open):**
+- feat: Backstage app-config with TCS branding
+- feat: software catalog - core entities
+- feat: golden path template - Node.js microservice
+- feat: golden path template - Python service
+- feat: TechDocs MkDocs integration
+- feat: platform blueprints - microservices pattern
+- feat: platform blueprints - event-driven pattern
+- docs: IDP architecture and onboarding guide
+
+**Content:**
+- Backstage YAML configs, software templates
+- Meeting notes: `docs/meetings/2026-05-05-platform-team-standup.md`
+- Meeting notes: `docs/meetings/2026-05-12-blueprint-review.md`
+- Architecture diagram (Mermaid): IDP component architecture
+- Architecture diagram (Mermaid): service catalog entity relationships
+
+### Phase 3 - GitOps Adoption (May 12 - May 27)
+
+**Repos:** `argo-cd` fork, `keda`, `tcs-delivery-accelerators`, `tcs-integration-starters`
+**Accounts:** All 13
+
+**Issues:**
+- ArgoCD RBAC and project isolation design
+- App-of-apps pattern vs ApplicationSet decision
+- KEDA scaling policy for event-driven services
+- KEDA HTTP add-on evaluation
+- Delivery pipeline template for microservices
+- Progressive delivery with Argo Rollouts
+- Integration starter for Kafka
+- Integration starter for RabbitMQ
+- Integration starter for REST APIs
+- Observability integration in delivery pipelines
+
+**PRs (mix of merged + open):**
+- feat: ArgoCD app-of-apps bootstrap
+- feat: ArgoCD ApplicationSet for team namespaces
+- feat: KEDA ScaledObject templates
+- feat: delivery accelerator - CI pipeline starter
+- feat: delivery accelerator - CD pipeline with ArgoCD
+- feat: integration starter - Kafka producer/consumer
+- feat: integration starter - REST API with OpenAPI
+- docs: GitOps adoption guide
+
+**Content:**
+- ArgoCD Application manifests, ApplicationSet specs
+- KEDA ScaledObject YAML templates
+- Helm chart starters
+- Meeting notes: `docs/meetings/2026-05-19-gitops-working-group.md`
+- Meeting notes: `docs/meetings/2026-05-26-delivery-retrospective.md`
+- Architecture diagram (Mermaid): GitOps delivery pipeline
+
+## Volume Targets
+
+| Type | Count |
+|------|-------|
+| Issues | ~40 |
+| PRs | ~25 (mix merged/open) |
+| Commits | ~60+ |
+| Meeting notes | 6 |
+| Architecture diagrams | 4 |
+| Code files | ~30 |
+
+## Execution Notes
+
+- Switch `gh` account per action: `gh auth switch --user <account>`
+- Use `--created-at` style backdating where GitHub API supports it; otherwise use commit date overrides via `GIT_AUTHOR_DATE` / `GIT_COMMITTER_DATE`
+- Issues and PR comments rotated across multiple accounts to simulate real team discussion
+- PRs should have review comments from at least one other account before merge
+- Meeting notes follow consistent template: attendees, agenda, decisions, action items