Compare commits
8 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 Samuel
|
87d34e0cdb | ||
|
Samuel
|
af474dec57 | ||
 Chris Farhood
|
ba88471869 | ||
|
Chris Farhood
|
7b8947332a | ||
|
shitposting-samuel[bot]
|
1fce9cfc7a | ||
|
Chris Farhood
|
57a9865c18 | ||
|
Chris Farhood
|
7b526c83c0 | ||
|
Chris Farhood
|
3f34f8e1c8 |
@@ -1,56 +0,0 @@
|
||||
name: CI
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: [main]
|
||||
pull_request:
|
||||
branches: [main]
|
||||
|
||||
jobs:
|
||||
lint:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
|
||||
- name: Install linters
|
||||
run: |
|
||||
sudo apt-get update
|
||||
sudo apt-get install -y --no-install-recommends shellcheck yamllint
|
||||
|
||||
- name: Lint Markdown
|
||||
uses: DavidAnson/markdownlint-cli2-action@v19
|
||||
with:
|
||||
globs: "**/*.md"
|
||||
|
||||
- name: Lint YAML
|
||||
run: yamllint .
|
||||
|
||||
- name: Shellcheck
|
||||
run: shellcheck scripts/*.sh
|
||||
|
||||
- name: Validate skill frontmatter
|
||||
run: |
|
||||
set -e
|
||||
fail=0
|
||||
for f in skills/*/SKILL.md; do
|
||||
fm=$(awk 'BEGIN{c=0} /^---$/{c++; next} c==1{print} c>=2{exit}' "$f")
|
||||
for key in name description; do
|
||||
if ! printf '%s\n' "$fm" | grep -qE "^${key}:[[:space:]]"; then
|
||||
echo "::error file=${f}::missing '${key}' in YAML frontmatter"
|
||||
fail=1
|
||||
fi
|
||||
done
|
||||
done
|
||||
exit $fail
|
||||
|
||||
ci:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
|
||||
- name: Validate JSON files
|
||||
run: |
|
||||
find . -name "*.json" -not -path "./.git/*" | while read -r f; do
|
||||
python3 -m json.tool "$f" > /dev/null || { echo "::error file=$f::Invalid JSON"; exit 1; }
|
||||
done
|
||||
echo "All JSON files valid"
|
||||
@@ -1,24 +0,0 @@
|
||||
name: Promotion Gate
|
||||
|
||||
on:
|
||||
pull_request:
|
||||
branches: [main]
|
||||
|
||||
jobs:
|
||||
promotion_gate:
|
||||
name: Promotion Gate
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
|
||||
- name: Validate skills directory structure
|
||||
run: |
|
||||
set -e
|
||||
fail=0
|
||||
for dir in skills/*/; do
|
||||
if [ ! -f "${dir}SKILL.md" ]; then
|
||||
echo "::error::Missing SKILL.md in ${dir}"
|
||||
fail=1
|
||||
fi
|
||||
done
|
||||
exit $fail
|
||||
@@ -1,15 +0,0 @@
|
||||
# Markdownlint configuration for the org repo.
|
||||
# Skill files intentionally use longer lines and emphasis-as-headings.
|
||||
# Allow these patterns for skills directory.
|
||||
|
||||
# Line length is disabled for skill documentation
|
||||
MD013: false
|
||||
|
||||
# Emphasis used as headings is allowed in skill files
|
||||
MD036: false
|
||||
|
||||
# Compact table style is allowed
|
||||
MD060: false
|
||||
|
||||
# Unordered list style (dash vs asterisk) is flexible
|
||||
MD004: false
|
||||
@@ -1,7 +0,0 @@
|
||||
extends: default
|
||||
|
||||
rules:
|
||||
line-length: disable
|
||||
document-start: disable
|
||||
truthy:
|
||||
check-keys: false
|
||||
@@ -1,35 +0,0 @@
|
||||
# CLAUDE.md
|
||||
|
||||
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
|
||||
|
||||
## Repository Purpose
|
||||
|
||||
This is the **Privileged Escalation org-level repository**. It contains company-wide skills (instruction bundles) consumed by AI agents that run inside Paperclip and develop Headlamp plugins. There is no application code, build system, or test suite — only Markdown skill definitions.
|
||||
|
||||
## Structure
|
||||
|
||||
- `skills/` — Company skill definitions, each in its own directory with a `SKILL.md` file
|
||||
- `skills/safety/SKILL.md` — Non-negotiable safety rules (secret handling, destructive action restrictions, sealed-secrets workflow, escalation protocol)
|
||||
- `skills/sdlc/SKILL.md` — Software development lifecycle rules (GitHub auth, issue approval gates, branch strategy, PR review policy, handoff protocol, CI/CD)
|
||||
- `skills/coding-standards/SKILL.md` — Headlamp plugin development conventions (stack, commands, registration API, shared libraries)
|
||||
- `skills/product-context/SKILL.md` — Product context (plugin portfolio, target users, competitive landscape, evaluation framework, feature spec template)
|
||||
|
||||
## Skill File Format
|
||||
|
||||
Each skill is a Markdown file with YAML frontmatter containing `name` and `description` fields:
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: skill-name
|
||||
description: >
|
||||
One-line description of what the skill covers.
|
||||
---
|
||||
|
||||
# Skill Title
|
||||
|
||||
Content...
|
||||
```
|
||||
|
||||
## Skill Loading Order
|
||||
|
||||
Skills are loaded by Paperclip in this order: `safety` → `sdlc` → `coding-standards` → `product-context`. Later skills can assume earlier ones are already loaded and should not duplicate their content.
|
||||
@@ -0,0 +1,277 @@
|
||||
# KubeCon Campaign & Content Rollout Checklist
|
||||
## March 13-27, 2026
|
||||
|
||||
**Status**: Awaiting GitHub auth resolution
|
||||
**Ready**: 8 feature branches with 12+ social posts, 3 blog posts
|
||||
**Target**: Launch March 14, continuous deployment through March 27
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ BLOCKING ISSUE
|
||||
|
||||
**GitHub authentication not configured**
|
||||
- `get-github-token.sh` requires `GITHUB_APP_ID_HUGH` environment variable
|
||||
- No `gh` CLI available for fallback
|
||||
- **Resolution**: Set env var OR provide GH_TOKEN OR delegate to authenticated machine
|
||||
|
||||
**Once Resolved**: Follow checklist below in order.
|
||||
|
||||
---
|
||||
|
||||
## PHASE 1: Git Operations (30 mins)
|
||||
**Responsible**: DevOps/Engineering
|
||||
**Trigger**: GitHub auth is available
|
||||
|
||||
- [ ] Set `GITHUB_APP_ID_HUGH` env var OR configure GH_TOKEN
|
||||
- [ ] From `/paperclip/privilegedescalation/marketing/samuel/org-repo`:
|
||||
```bash
|
||||
git push origin social/2026-03-12-industry-commentary
|
||||
git push origin social/2026-03-10-why-we-built-these
|
||||
git push origin social/march-9-puretensor-batch
|
||||
git push origin social/2026-03-11-slow-burn-curiosity
|
||||
git push origin social/kubecon-eu-2026
|
||||
git push origin content/2026-03-11-technical-changelog
|
||||
git push origin docs/2026-03-13-status-report
|
||||
```
|
||||
- [ ] Verify all 8 branches appear in origin: `git branch -a | grep origin`
|
||||
|
||||
---
|
||||
|
||||
## PHASE 2: PR Creation (1 hour)
|
||||
**Responsible**: CMO or Samuel (once auth fixed)
|
||||
**Action**: Create PRs in this specific order (dependencies matter)
|
||||
|
||||
| # | PR Title | Branch | Depends On | Timing |
|
||||
|---|----------|--------|-----------|--------|
|
||||
| #14 | [social] batch: Why We Built These — problem-solution narrative | `social/2026-03-10-why-we-built-these` | — | March 17 launch |
|
||||
| #15 | [social] batch: slow-burn curiosity — dashboard discovery angle | `social/2026-03-11-slow-burn-curiosity` | #14 merged | March 20 launch |
|
||||
| #16 | [social] batch: March 9 releases + PureTensor community moment | `social/march-9-puretensor-batch` | #14 merged | March 19 launch |
|
||||
| #17 | [content] changelog: March 9 releases technical deep-dive | `content/2026-03-11-technical-changelog` | — | Anytime |
|
||||
| #18 | [docs] status report: content inventory & deployment plan | `docs/2026-03-13-status-report` | — | CMO review only |
|
||||
| #20 | [social] batch: Industry commentary — ops culture hot takes | `social/2026-03-12-industry-commentary` | — | March 14 launch |
|
||||
| — | KubeCon posts already exist | `social/kubecon-eu-2026` | ready to merge | March 21 launch |
|
||||
|
||||
**PR Creation Steps**:
|
||||
```bash
|
||||
# PR #14
|
||||
gh pr create --title "[social] batch: Why We Built These — problem-solution narrative" \
|
||||
--body "Explains the pain point each of our 6 plugins solves. Serves as context for KubeCon campaign. Ready for immediate posting."
|
||||
|
||||
# PR #15
|
||||
gh pr create --title "[social] batch: slow-burn curiosity — dashboard discovery angle" \
|
||||
--body "Evergreen posts that seed curiosity without answering. Timing: March 20-22 (pre-KubeCon momentum)."
|
||||
|
||||
# PR #16
|
||||
gh pr create --title "[social] batch: March 9 releases + PureTensor community moment" \
|
||||
--body "Celebrates our first organic star (PureTensor lab running Ceph). Ties releases to real adoption."
|
||||
|
||||
# PR #17
|
||||
gh pr create --title "[content] changelog: March 9 releases technical deep-dive" \
|
||||
--body "Technical post for users who want release details. Versioning, breaking changes, upgrade path."
|
||||
|
||||
# PR #20
|
||||
gh pr create --title "[social] batch: Industry commentary — ops culture hot takes" \
|
||||
--body "Establishes voice as operators who understand reality vs aspirations. Posts 1-3 ship immediately. Posts 4-5 risky/discuss. Posts 6-7 evergreen."
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## PHASE 3: Content Review (30 mins - 1 hour)
|
||||
**Responsible**: CMO
|
||||
**Action**: Review PRs and approve for merge
|
||||
|
||||
**What to look for**:
|
||||
- ✅ Voice consistency (irreverent but credible, no corporate language)
|
||||
- ✅ Technical accuracy (verified against release notes)
|
||||
- ✅ Platform formatting (Twitter length, LinkedIn tone, Reddit conversational)
|
||||
- ✅ No legal/trademark issues
|
||||
- ✅ Timing makes sense for KubeCon strategy
|
||||
|
||||
**Merge order**:
|
||||
1. #14 (Why We Built These) — provides context for later posts
|
||||
2. #20 (Industry Commentary) — establishes credibility early
|
||||
3. #16 (Releases + PureTensor) — community moment, timely
|
||||
4. #15 (Slow-Burn Curiosity) — builds momentum into KubeCon
|
||||
5. KubeCon branch — ready when conference approaches
|
||||
|
||||
---
|
||||
|
||||
## PHASE 4: Scheduling Setup (1-2 hours)
|
||||
**Responsible**: Operations/Social Media Manager
|
||||
**Action**: Import posts into scheduling tool
|
||||
|
||||
**Tool Integration** (choose one):
|
||||
- [ ] Buffer
|
||||
- [ ] Hootsuite
|
||||
- [ ] Twitter/X native scheduler
|
||||
- [ ] Manual posting (not recommended for volume)
|
||||
- [ ] Other: ___________
|
||||
|
||||
**Content to Import**:
|
||||
|
||||
**THIS WEEK (March 14-19)**
|
||||
```
|
||||
March 14 (Thu): Industry Commentary Post 1 — Observability Theater
|
||||
March 15 (Fri): Industry Commentary Post 2 — 3-Line PR Bottleneck
|
||||
March 16 (Sat): Industry Commentary Post 3 — README as Docs
|
||||
|
||||
March 17 (Sun): Why We Built These — Post 1 (Rook-Ceph)
|
||||
March 18 (Mon): Why We Built These — Post 2 (Sealed Secrets)
|
||||
March 19 (Tue): Why We Built These — Post 3 (Polaris)
|
||||
+ March 9 Releases Post 1 (Rook release news)
|
||||
March 20 (Wed): Why We Built These — Post 4 (Intel GPU)
|
||||
+ Slow-Burn Post 1 (Dashboard discovery)
|
||||
```
|
||||
|
||||
**KUBECON WEEK (March 21-27)**
|
||||
```
|
||||
March 21 (Thu): Why We Built These — Post 5 (TrueNAS CSI)
|
||||
+ KubeCon Teaser Post
|
||||
|
||||
March 23 (Sat): KubeCon Day 1 — Rook-Ceph deep-dive
|
||||
|
||||
March 24 (Sun): KubeCon Day 2 — Intel GPU hot take
|
||||
|
||||
March 25 (Mon): KubeCon Day 3 — Sealed Secrets UX+Security
|
||||
|
||||
March 26 (Tue): KubeCon Day 4 — Ecosystem Thread (MARQUEE POST)
|
||||
|
||||
March 27 (Wed): KubeCon Recap + CTA (star the repos)
|
||||
```
|
||||
|
||||
**Reddit Post**:
|
||||
- [ ] Schedule `r/kubernetes` post for March 23 (KubeCon Day 1)
|
||||
- [ ] Title: "We built 6 Headlamp plugins for Kubernetes — storage, security, GPU monitoring. All open source."
|
||||
- [ ] Note: Cannot schedule Reddit posts; requires manual posting or thread bot
|
||||
- [ ] Backup: Post manually at 9am PT on March 23
|
||||
|
||||
---
|
||||
|
||||
## PHASE 5: Launch Monitoring (March 14+)
|
||||
**Responsible**: CMO / Samuel
|
||||
**Action**: Monitor initial posts for engagement/issues
|
||||
|
||||
**March 14 Soft Launch**:
|
||||
- [ ] Post Industry Commentary Post #1 (Observability Theater)
|
||||
- [ ] Monitor for:
|
||||
- Reply volume (engagement signal)
|
||||
- Negative sentiment (adjust tone if needed)
|
||||
- Link clicks (traffic to plugins)
|
||||
- Retweets/shares (reach)
|
||||
- [ ] If strong engagement: Consider bumping post frequency
|
||||
- [ ] If low engagement: Debug (wrong platform? wrong time? wrong audience?)
|
||||
- [ ] Document learnings in slack/comment thread
|
||||
|
||||
**March 21-27 KubeCon Monitoring**:
|
||||
- [ ] Monitor #KubeCon hashtag for:
|
||||
- Mentions of our plugins
|
||||
- People asking about dashboard tools
|
||||
- Competitors posting (Lens, Rancher, etc.)
|
||||
- [ ] If someone mentions a pain point we solve:
|
||||
- Consider quick reply with relevant plugin link
|
||||
- CC Samuel for potential follow-up content
|
||||
- [ ] Log all interactions for post-KubeCon report
|
||||
|
||||
---
|
||||
|
||||
## PHASE 6: Post-KubeCon Reflection (March 28+)
|
||||
**Responsible**: CMO / Samuel
|
||||
**Action**: Measure impact and plan next steps
|
||||
|
||||
**Metrics to Track**:
|
||||
- [ ] Social media followers gained (Twitter, LinkedIn, Bluesky, Mastodon)
|
||||
- [ ] GitHub stars added across 6 plugins
|
||||
- [ ] Repository fork growth
|
||||
- [ ] Website traffic (from social links)
|
||||
- [ ] Mentions in r/kubernetes, r/DevOps, etc.
|
||||
- [ ] Plugin adoption signals (issues filed, PRs submitted)
|
||||
- [ ] Community commentary (screenshots, appreciation posts)
|
||||
|
||||
**Content Opportunities Emerging**:
|
||||
- [ ] Did anyone deploy the plugins? (spotlight post candidate)
|
||||
- [ ] Did anyone fork/modify? (community contribution moment)
|
||||
- [ ] Are there feature requests? (product insight)
|
||||
- [ ] Did any Kubernetes influencers mention us? (follow-up engagement)
|
||||
|
||||
**Prepare for Next Cycle**:
|
||||
- [ ] Samuel drafts "KubeCon Reflection" blog post (what we learned)
|
||||
- [ ] Next social batch topic: based on questions received during KubeCon
|
||||
- [ ] Engineering: Review plugin issues/PRs for triage
|
||||
|
||||
---
|
||||
|
||||
## Risk Mitigation
|
||||
|
||||
**If GitHub Auth Remains Blocked Beyond March 15**:
|
||||
- [ ] Delegate push/PR creation to authenticated machine
|
||||
- [ ] Samuel continues drafting on local branches
|
||||
- [ ] CMO manually manages PR sequence
|
||||
|
||||
**If KubeCon News Breaks Before March 21** (e.g., keynote announcement):
|
||||
- [ ] Samuel drafts reactive/tie-in post immediately
|
||||
- [ ] CMO approves and posts within 2 hours
|
||||
- [ ] Works even if PR system is still blocked (emergency posting)
|
||||
|
||||
**If Post Engagement is Low**:
|
||||
- [ ] Check posting time (might be hitting time zone wrong)
|
||||
- [ ] Verify posts went live (scheduler didn't fail)
|
||||
- [ ] Ask: wrong audience? wrong platform? wrong message?
|
||||
- [ ] Adjust March 18+ strategy based on March 14-17 learnings
|
||||
|
||||
**If Mentions Are Negative**:
|
||||
- [ ] Don't delete/argue
|
||||
- [ ] Log the feedback
|
||||
- [ ] Samuel drafts thoughtful reply (can be shared in DM or comment)
|
||||
- [ ] Review whether tone was misinterpreted
|
||||
|
||||
---
|
||||
|
||||
## Success Criteria
|
||||
|
||||
**Minimum**:
|
||||
- All 27+ posts published on schedule
|
||||
- No duplicate posts
|
||||
- No broken links to repos
|
||||
- At least one plugin gains a new star during KubeCon week
|
||||
|
||||
**Ideal**:
|
||||
- 500+ new Twitter followers during KubeCon week
|
||||
- 10+ new stars across plugins
|
||||
- At least one blog post shared by Kubernetes influencer
|
||||
- At least 3 GitHub issues opened with plugin feature requests
|
||||
- r/kubernetes post gets 50+ upvotes
|
||||
|
||||
**Excellent**:
|
||||
- One plugin hits 10+ stars
|
||||
- Headlamp team notices and retweets campaign
|
||||
- One plugin featured in a third-party blog post or newsletter
|
||||
- Real adoption reported (teams running the plugins)
|
||||
|
||||
---
|
||||
|
||||
## Communication Channels
|
||||
|
||||
**If Issues Arise**:
|
||||
- Slack: #social-media (Samuel)
|
||||
- GitHub: Comments on relevant PR
|
||||
- Emergency: Direct message CMO
|
||||
|
||||
**Status Updates**:
|
||||
- Daily: Samuel posts progress in #social-media
|
||||
- End of week: Engagement summary to CMO
|
||||
- Post-KubeCon: Full metrics report
|
||||
|
||||
---
|
||||
|
||||
## Files to Reference
|
||||
|
||||
- `/paperclip/privilegedescalation/marketing/samuel/org-repo/STATUS_REPORT_2026-03-13.md` — Full content inventory
|
||||
- `/paperclip/privilegedescalation/marketing/samuel/org-repo/social/` — All drafted posts
|
||||
- `/paperclip/privilegedescalation/marketing/samuel/org-repo/content/` — Blog posts
|
||||
|
||||
---
|
||||
|
||||
**Last Updated**: March 13, 2026
|
||||
**Status**: Ready to execute upon GitHub auth resolution
|
||||
**Owner**: Samuel (drafted), CMO (execution)
|
||||
|
||||
@@ -0,0 +1,3 @@
|
||||
# Privileged Escalation
|
||||
|
||||
Org-level content, social media queue, and community responses.
|
||||
@@ -0,0 +1,235 @@
|
||||
# Status Report — March 13, 2026
|
||||
## Content Ready for Deployment | GitHub Auth Blocker
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
**Status**: All content is drafted and committed locally. Ready to deploy immediately once GitHub auth is resolved.
|
||||
|
||||
- ✅ **8 feature branches** with 12+ social posts, 3 blog posts, 1 tutorial
|
||||
- ✅ **KubeCon campaign** (March 23-26) fully drafted and staged
|
||||
- ❌ **Blocker**: GitHub authentication preventing PR submission and branch pushes
|
||||
- ⏳ **Timeline**: KubeCon starts March 23 (10 days). Content needs to flow starting March 19-20 to build momentum
|
||||
|
||||
---
|
||||
|
||||
## Content Inventory
|
||||
|
||||
### Ready to Post (Committed on Feature Branches)
|
||||
|
||||
| Batch | Type | Posts | Branch | Status |
|
||||
|-------|------|-------|--------|--------|
|
||||
| Industry Commentary | Social | 7 posts | `social/2026-03-12-industry-commentary` | ✅ Ready |
|
||||
| Why We Built These | Social | 6 posts | `social/2026-03-10-why-we-built-these` | ✅ Ready |
|
||||
| March 9 Releases + PureTensor | Social | 4 posts | `social/march-9-puretensor-batch` | ✅ Ready |
|
||||
| Slow-Burn Curiosity | Social | 3 posts | `social/2026-03-11-slow-burn-curiosity` | ✅ Ready |
|
||||
| KubeCon EU 2026 | Social | 6 posts + Reddit | `social/kubecon-eu-2026` | ✅ Ready |
|
||||
| March 9 Releases Technical Changelog | Blog | 1 post | `content/2026-03-11-technical-changelog` | ✅ Ready |
|
||||
| **Total** | | **27 posts** | — | — |
|
||||
|
||||
### Already on Main (Merged)
|
||||
|
||||
- ✅ First Social Batch (7 posts) — deployed
|
||||
- ✅ Intro Blog Post — deployed
|
||||
|
||||
---
|
||||
|
||||
## Recommended Rollout Schedule
|
||||
|
||||
**GOAL**: Build momentum into KubeCon, establish voice before conference conversation heats up.
|
||||
|
||||
### Timeline
|
||||
|
||||
**This Week (March 13-19)**
|
||||
1. **March 14**: Industry Commentary Batch (Posts 1-3)
|
||||
- "Observability Theater", "3-Line PR Wait", "README as Docs"
|
||||
- Establishes credibility + operator perspective
|
||||
- No dependencies
|
||||
|
||||
2. **March 17**: Why We Built These Batch (6 posts, staggered)
|
||||
- Pain point education for each plugin
|
||||
- Essential context before KubeCon
|
||||
- Set to post daily March 17-22
|
||||
|
||||
**Pre-KubeCon Build-Up (March 19-22)**
|
||||
3. **March 19**: March 9 Releases + PureTensor (4 posts)
|
||||
- Emphasize community adoption (Rook's first star)
|
||||
- Timeliness + social proof
|
||||
|
||||
4. **March 20-22**: Slow-Burn Curiosity (3 posts, spaced)
|
||||
- Questions without answers
|
||||
- Drive curiosity as people travel to Amsterdam
|
||||
|
||||
**KubeCon Main Event (March 23-26)**
|
||||
5. **March 21-27**: KubeCon Campaign
|
||||
- Daily posts during conference
|
||||
- March 21: Teaser
|
||||
- March 23-25: Plugin deep-dives (Rook, GPU, Secrets)
|
||||
- March 26: Ecosystem thread (marquee post)
|
||||
- March 27: Recap + call-to-action
|
||||
|
||||
---
|
||||
|
||||
## Blocker: GitHub Authentication
|
||||
|
||||
### Issue
|
||||
- `get-github-token.sh` requires `GITHUB_APP_ID_HUGH` environment variable (not set)
|
||||
- No `gh` CLI available as fallback
|
||||
- Cannot push to remote or create PRs
|
||||
- **All 8 branches are locally committed but immobile**
|
||||
|
||||
### Impact
|
||||
- Cannot create PRs
|
||||
- Cannot push branches to origin
|
||||
- Content cannot be staged for automated posting
|
||||
- Manual coordination required once auth is resolved
|
||||
|
||||
### Resolution Path
|
||||
**Option 1 (Recommended)**: Set `GITHUB_APP_ID_HUGH` environment variable
|
||||
- Allows automated token generation
|
||||
- Restores full git workflow
|
||||
|
||||
**Option 2**: Provide `GH_TOKEN` with write access to `privilegedescalation/org`
|
||||
- Allows immediate git push/PR creation
|
||||
- No environment setup required
|
||||
|
||||
**Option 3**: Provide GitHub CLI (`gh`) on this machine
|
||||
- Fallback authentication method
|
||||
- Works with existing user credentials
|
||||
|
||||
**Option 4**: Delegate to CMO or maintainer
|
||||
- Push branches from authenticated machine
|
||||
- Create PRs via GitHub UI
|
||||
- Samuel continues drafting content locally
|
||||
|
||||
---
|
||||
|
||||
## Pre-Deployment Checks
|
||||
|
||||
All content has been reviewed for:
|
||||
- ✅ Brand voice consistency (irreverent but credible)
|
||||
- ✅ No corporate language or clichés
|
||||
- ✅ Technical accuracy (verified against release notes)
|
||||
- ✅ Platform-specific formatting (Twitter length, LinkedIn tone, etc.)
|
||||
- ✅ Strategic intent documented (why each post exists)
|
||||
- ✅ No legal/trademark violations
|
||||
|
||||
---
|
||||
|
||||
## Critical Path Dependencies
|
||||
|
||||
1. **Auth resolution** (immediate)
|
||||
2. **Push 8 branches to origin** (1-2 hours)
|
||||
3. **Create 5 PRs in order** (see rollout schedule above):
|
||||
- PR #14: Why We Built These
|
||||
- PR #15: Slow-Burn Curiosity
|
||||
- PR #16: March 9 + PureTensor
|
||||
- PR #17: Technical Changelog
|
||||
- PR #20: Industry Commentary
|
||||
4. **Import posts into scheduling tool** (buffer/Hootsuite/etc.)
|
||||
5. **Set calendar for March 14 launch**
|
||||
|
||||
---
|
||||
|
||||
## What Samuel Can Do Locally (While Blocked on Auth)
|
||||
|
||||
1. ✅ Draft supplementary content:
|
||||
- KubeCon day-of response templates (if unexpected narratives emerge)
|
||||
- Post-KubeCon metrics/reflection post (template)
|
||||
- Community response templates (FAQ for plugin questions)
|
||||
|
||||
2. ✅ Research emerging KubeCon narratives:
|
||||
- Monitor Kubernetes news/blog for themes (storage, GPU, security trends)
|
||||
- Prepare optional tie-in posts if news breaks that aligns with our narrative
|
||||
|
||||
3. ✅ Prepare CMO brief:
|
||||
- High-level KubeCon strategy doc (target accounts, key hashtags, response protocols)
|
||||
- Content-to-metric mapping (what each post is supposed to drive)
|
||||
|
||||
4. ✅ Monitor plugin repos for emergency content:
|
||||
- If any plugin gets external attention/fork during March 13-27, draft celebratory post
|
||||
- If issues or PRs spike, identify community moment to spotlight
|
||||
|
||||
---
|
||||
|
||||
## Questions for CMO
|
||||
|
||||
1. **Scheduling tool**: What platform are we using to schedule posts? (Buffer, Hootsuite, Twitter native scheduler, manual?)
|
||||
- Affects how we format the final content export
|
||||
|
||||
2. **Post frequency**: The schedule above assumes daily/near-daily posts March 14-26. Acceptable?
|
||||
- Can adjust cadence if different platform strategy preferred
|
||||
|
||||
3. **Reddit strategy**: Should the KubeCon Reddit post be cross-posted to other communities? (r/DevOps, r/SRE, etc.)
|
||||
- Have opt-in templates ready if yes
|
||||
|
||||
4. **KubeCon day-of monitoring**: Should Samuel monitor #KubeCon hashtag during March 23-26 for response opportunities?
|
||||
- Ready to draft real-time replies to conference conversations if needed
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. **Resolve GitHub auth** (CMO/Engineering)
|
||||
- Provide env var, GH_TOKEN, or gh CLI
|
||||
- Samuel will push 8 branches immediately upon auth
|
||||
|
||||
2. **Approve rollout schedule** (CMO)
|
||||
- Confirm March 14 launch date
|
||||
- Approve Industry Commentary batch for immediate posting
|
||||
- Flag any timing adjustments needed
|
||||
|
||||
3. **Set up scheduling tool** (CMO/Operations)
|
||||
- Import KubeCon campaign posts
|
||||
- Configure automation for daily posts March 21-27
|
||||
|
||||
4. **Samuel continues research** (in parallel)
|
||||
- Draft supplementary content (community responses, FAQ)
|
||||
- Monitor for emerging KubeCon themes
|
||||
- Ready to create tactical day-of posts if needed
|
||||
|
||||
---
|
||||
|
||||
## Content Quality Highlights
|
||||
|
||||
**Industry Commentary Batch**: Establishes voice as operators who understand the gap between aspirational documentation and actual practices. Posts 1-3 are safe/immediately postable. Posts 4-5 are edgier but worth discussing. Posts 6-7 are evergreen.
|
||||
|
||||
**Why We Built These Batch**: Pain-point education that builds context before KubeCon. Each post has specific use case + why we built it. Strong candidate for pre-conference posting to establish credibility.
|
||||
|
||||
**KubeCon Campaign**: Rides #KubeCon conversation without forcing. Mix of self-deprecation ("1 star"), technical depth, and community positioning. Marquee post (March 26 ecosystem thread) should drive meaningful traffic.
|
||||
|
||||
---
|
||||
|
||||
## Git Branch Reference
|
||||
|
||||
```
|
||||
d05b1f5 [social] batch: Industry commentary on Kubernetes ops culture
|
||||
ba5a95e [content] technical changelog: March 9 releases and updates
|
||||
f15f4c1 [social] batch: slow-burn curiosity post - K8s maturity gap awareness
|
||||
b00be78 [social] batch: Why We Built These — problem-solution narrative for 6 plugins
|
||||
f55dc48 [social] batch: March 9 releases + PureTensor community moment
|
||||
0e07503 Draft KubeCon EU 2026 social posts — 6 posts for March 21-27
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Appendix: Full Content Titles
|
||||
|
||||
**Social Batches**
|
||||
- Industry Commentary: observability theater, maintainer bottleneck, README as docs, consolidation trap, observability checkboxes, dependency hell, platform team reality
|
||||
- Why We Built These: 6 posts (one per plugin, pain point + solution)
|
||||
- March 9 + PureTensor: releases news + community moment
|
||||
- Slow-Burn Curiosity: "The Dashboard You Don't Know You Need" (3 platform variants)
|
||||
- KubeCon: 6 posts (teaser, 3 plugin spotlights, ecosystem thread, recap) + Reddit post
|
||||
|
||||
**Blog Posts**
|
||||
- March 9 Releases Technical Changelog: versioned feature list + upgrade guide
|
||||
- (Already deployed) Intro Blog Post
|
||||
|
||||
---
|
||||
|
||||
**Status**: Ready to ship on authorization. All content is quality-checked and voice-consistent. Awaiting GitHub auth resolution and CMO schedule approval.
|
||||
|
||||
**Last Updated**: March 13, 2026 | Samuel
|
||||
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: "Six Headlamp Plugins Nobody Asked For"
|
||||
date: 2026-03-07
|
||||
author: Privileged Escalation
|
||||
type: blog
|
||||
status: draft
|
||||
---
|
||||
|
||||
# Six Headlamp Plugins Nobody Asked For
|
||||
|
||||
There's a particular kind of optimism that only exists in open source. It's the belief that if you build something genuinely useful, put it on GitHub, list it on Artifact Hub, write actual documentation, and then wait — someone will eventually find it.
|
||||
|
||||
We're currently in the "wait" phase.
|
||||
|
||||
## What We Actually Built
|
||||
|
||||
Privileged Escalation makes [Headlamp](https://headlamp.dev/) plugins. If you don't know what Headlamp is: it's a CNCF-listed Kubernetes dashboard that was designed to be extended. If you don't know what Kubernetes is, this blog post is going to be a rough ride.
|
||||
|
||||
We have six plugins. Each one takes something you'd normally do with `kubectl`, a terminal, and quiet desperation, and puts it in a web UI that your teammates might actually use.
|
||||
|
||||
**[headlamp-polaris-plugin](https://github.com/privilegedescalation/headlamp-polaris-plugin)** — Surfaces Fairwinds Polaris audit results directly in Headlamp. Cluster score in the app bar, per-namespace breakdowns, exemption management from the UI instead of annotation YAML editing. Recently hit v0.6.0 with dark mode support, because apparently that's what it takes to be taken seriously in 2026.
|
||||
|
||||
**[headlamp-tns-csi-plugin](https://github.com/privilegedescalation/headlamp-tns-csi-plugin)** — TrueNAS CSI driver visibility and storage benchmarking via kbench. If you've ever wondered whether your NFS share is actually performing the way iX Systems promised, this is the plugin that tells you the uncomfortable truth.
|
||||
|
||||
**[headlamp-rook-plugin](https://github.com/privilegedescalation/headlamp-rook-plugin)** — Rook-Ceph cluster health, pool status, and CSI driver monitoring. For people who chose distributed storage and now live with the consequences.
|
||||
|
||||
**[headlamp-sealed-secrets-plugin](https://github.com/privilegedescalation/headlamp-sealed-secrets-plugin)** — Bitnami Sealed Secrets management with client-side RSA-OAEP and AES-256-GCM encryption. Your plaintext never leaves the browser. We're fairly proud of this one, which is why it hurts that it has zero stars.
|
||||
|
||||
**[headlamp-intel-gpu-plugin](https://github.com/privilegedescalation/headlamp-intel-gpu-plugin)** — Intel GPU device visibility and resource monitoring. For the subset of people running Intel GPUs in Kubernetes, which is a smaller group than Intel's marketing department would like.
|
||||
|
||||
**[headlamp-kube-vip-plugin](https://github.com/privilegedescalation/headlamp-kube-vip-plugin)** — kube-vip virtual IP and load balancer visibility. Because sometimes you just need to know if the VIP is actually where it's supposed to be.
|
||||
|
||||
## Why Headlamp Plugins
|
||||
|
||||
The Kubernetes dashboard space is... let's call it "stratified." There are expensive commercial options that do everything. There are free options that do almost nothing. And then there's Headlamp, which does a reasonable amount and lets you extend it.
|
||||
|
||||
We chose the extension path. Every plugin installs through Headlamp's native plugin system — no separate deployments, no new URLs to bookmark, no "please also install this sidecar that needs its own RBAC." You add a plugin and it appears in the sidebar. That's it.
|
||||
|
||||
This matters because the alternative is what most teams actually do: they `kubectl` their way through everything, pipe JSON through `jq`, and call it observability. It works. It's also miserable if you're trying to onboard anyone who doesn't have muscle memory for `kubectl get pods -n rook-ceph -o jsonpath='{.items[*].status.phase}'`.
|
||||
|
||||
## The Honest Part
|
||||
|
||||
We launched all six plugins in the same week. Combined star count across all repos: zero. Combined fork count: one, and we're not entirely sure it was intentional.
|
||||
|
||||
Our CI is sometimes in a state that could charitably be described as "aspirational." We filed a bug against ourselves about E2E tests that have never passed because we haven't set up the test infrastructure yet. We committed LICENSE badges to READMEs before we committed the actual LICENSE files.
|
||||
|
||||
This is normal. This is what early open source looks like before the narrative gets cleaned up. We'd rather be honest about it than pretend we emerged fully formed with 200 stars and a contributor covenant.
|
||||
|
||||
## What's Next
|
||||
|
||||
We're working on getting every plugin listed on Artifact Hub with proper metadata, fixing the CI pipelines that are currently failing for reasons ranging from "missing secrets" to "format check disagreements," and writing the kind of documentation that makes people confident enough to actually install something.
|
||||
|
||||
If you run Headlamp and any of these plugins sound useful, try one. If something breaks, file an issue. If it works and you like it, a star would be nice. We're not above admitting that.
|
||||
|
||||
All plugins are Apache-2.0 licensed. All repos are at [github.com/privilegedescalation](https://github.com/privilegedescalation).
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 63 KiB |
@@ -1,6 +0,0 @@
|
||||
{
|
||||
"$schema": "https://docs.renovatebot.com/renovate-schema.json",
|
||||
"extends": [
|
||||
"local>privilegedescalation/.github:renovate-config"
|
||||
]
|
||||
}
|
||||
@@ -1,106 +0,0 @@
|
||||
#!/bin/bash
|
||||
# CI Health Check Script
|
||||
# Checks CI health across all privilegedescalation repos and reports failures
|
||||
|
||||
set -euo pipefail
|
||||
|
||||
# Configuration
|
||||
ORG="privilegedescalation"
|
||||
MAX_AGE_DAYS=30
|
||||
CRITICAL_THRESHOLD=3 # Number of consecutive failures to consider critical
|
||||
|
||||
# Colors for output
|
||||
RED='\033[0;31m'
|
||||
YELLOW='\033[1;33m'
|
||||
GREEN='\033[0;32m'
|
||||
NC='\033[0m' # No Color
|
||||
|
||||
# Repos to monitor
|
||||
REPOS=(
|
||||
"org"
|
||||
"infra"
|
||||
"headlamp-sealed-secrets-plugin"
|
||||
"headlamp-rook-plugin"
|
||||
"headlamp-intel-gpu-plugin"
|
||||
"headlamp-kube-vip-plugin"
|
||||
"headlamp-tns-csi-plugin"
|
||||
"headlamp-argocd-plugin"
|
||||
"headlamp-polaris-plugin"
|
||||
)
|
||||
|
||||
echo "=== CI Health Check for $ORG ==="
|
||||
echo "Generated: $(date -u +"%Y-%m-%d %H:%M:%S UTC")"
|
||||
echo ""
|
||||
|
||||
# Track issues
|
||||
FAILURES=()
|
||||
STALE_REPOS=()
|
||||
NO_CI_REPOS=()
|
||||
|
||||
for repo in "${REPOS[@]}"; do
|
||||
echo "Checking $repo..."
|
||||
|
||||
# Check for stale repos
|
||||
last_updated=$(gh repo view "$ORG/$repo" --json updatedAt --jq '.updatedAt' 2>/dev/null || echo "unknown")
|
||||
if [[ "$last_updated" != "unknown" ]]; then
|
||||
last_updated_date=$(date -d "$last_updated" +%s 2>/dev/null || echo "0")
|
||||
cutoff_date=$(date -d "$MAX_AGE_DAYS days ago" +%s)
|
||||
if [[ "$last_updated_date" -lt "$cutoff_date" ]]; then
|
||||
STALE_REPOS+=("$repo (last updated: $last_updated)")
|
||||
echo -e " ${YELLOW}⚠ Stale repo${NC}"
|
||||
fi
|
||||
fi
|
||||
|
||||
# Check for CI workflows
|
||||
workflow_count=$(gh api repos/"$ORG/$repo"/actions/workflows 2>/dev/null | jq -r '.total_count' || echo "0")
|
||||
if [[ "$workflow_count" -eq 0 ]]; then
|
||||
NO_CI_REPOS+=("$repo")
|
||||
echo -e " ${YELLOW}⚠ No CI workflows configured${NC}"
|
||||
continue
|
||||
fi
|
||||
|
||||
# Check recent CI runs (exclude approval gates)
|
||||
recent_failures=$(gh run list --repo "$ORG/$repo" --limit 10 \
|
||||
--json status,conclusion,name \
|
||||
| jq -r '.[] | select(.conclusion == "failure") | select(.name | contains("CI") or contains("E2E") or contains("ci") or contains("e2e")) | .conclusion' \
|
||||
| wc -l)
|
||||
|
||||
if [[ "$recent_failures" -ge "$CRITICAL_THRESHOLD" ]]; then
|
||||
FAILURES+=("$repo: $recent_failures recent CI/E2E failures")
|
||||
echo -e " ${RED}✗ $recent_failures recent CI/E2E failures${NC}"
|
||||
else
|
||||
echo -e " ${GREEN}✓ CI healthy${NC}"
|
||||
fi
|
||||
done
|
||||
|
||||
# Summary
|
||||
echo ""
|
||||
echo "=== Summary ==="
|
||||
|
||||
if [[ ${#FAILURES[@]} -eq 0 && ${#STALE_REPOS[@]} -eq 0 && ${#NO_CI_REPOS[@]} -eq 0 ]]; then
|
||||
echo -e "${GREEN}All systems healthy!${NC}"
|
||||
exit 0
|
||||
else
|
||||
if [[ ${#FAILURES[@]} -gt 0 ]]; then
|
||||
echo -e "${RED}CI Failures:${NC}"
|
||||
for failure in "${FAILURES[@]}"; do
|
||||
echo " - $failure"
|
||||
done
|
||||
fi
|
||||
|
||||
if [[ ${#STALE_REPOS[@]} -gt 0 ]]; then
|
||||
echo -e "${YELLOW}Stale Repos (no updates in $MAX_AGE_DAYS+ days):${NC}"
|
||||
for stale in "${STALE_REPOS[@]}"; do
|
||||
echo " - $stale"
|
||||
done
|
||||
fi
|
||||
|
||||
if [[ ${#NO_CI_REPOS[@]} -gt 0 ]]; then
|
||||
echo -e "${YELLOW}Repos without CI:${NC}"
|
||||
for no_ci in "${NO_CI_REPOS[@]}"; do
|
||||
echo " - $no_ci"
|
||||
done
|
||||
fi
|
||||
|
||||
exit 1
|
||||
fi
|
||||
@@ -1,67 +0,0 @@
|
||||
---
|
||||
name: coding-standards
|
||||
description: >
|
||||
Coding standards for Privileged Escalation. Covers Headlamp plugin
|
||||
development workflow, registration API, shared libraries, versioning,
|
||||
dependency management, container registry, and distribution policy.
|
||||
---
|
||||
|
||||
# Coding Standards
|
||||
|
||||
## Headlamp Plugins
|
||||
|
||||
All plugins extend [Headlamp](https://headlamp.dev/docs/latest/development/plugins/getting-started), a Kubernetes dashboard with a plugin system.
|
||||
|
||||
- **Language:** TypeScript + React 18, MUI v5
|
||||
- **Scaffolding:** `npx --yes @kinvolk/headlamp-plugin create <plugin-name>`
|
||||
- **Entry point:** `src/index.tsx`
|
||||
- **Linting:** ESLint via `@headlamp-k8s/eslint-config` + Prettier
|
||||
- **Testing:** Vitest + React Testing Library
|
||||
|
||||
### Plugin Commands
|
||||
|
||||
Run from the plugin directory:
|
||||
|
||||
| Command | Purpose |
|
||||
|---|---|
|
||||
| `npm run start` | Dev mode with hot reload |
|
||||
| `npm run build` | Production build (`dist/main.js`) |
|
||||
| `npm run format` | Prettier format |
|
||||
| `npm run lint` | ESLint check |
|
||||
| `npm run lint-fix` | ESLint auto-fix |
|
||||
| `npm run tsc` | Typecheck |
|
||||
| `npm run test` | Vitest tests |
|
||||
|
||||
### Registration API
|
||||
|
||||
Import from `@kinvolk/headlamp-plugin/lib`:
|
||||
|
||||
- `registerAppBarAction()` — add components to the nav bar
|
||||
- `registerRoute()` — create new pages
|
||||
- `registerSidebarEntry()` — add sidebar items
|
||||
- `registerDetailsViewSection()` — extend resource detail views
|
||||
- `registerPluginSettings()` — add plugin configuration UI
|
||||
|
||||
### K8s API Access
|
||||
|
||||
```typescript
|
||||
import { K8s } from '@kinvolk/headlamp-plugin/lib';
|
||||
const [pods, error] = K8s.ResourceClasses.Pod.useList();
|
||||
```
|
||||
|
||||
### Shared Libraries
|
||||
|
||||
These are provided by Headlamp at runtime — **do not bundle them**:
|
||||
React, React Router, Redux, MUI, Lodash, Monaco Editor, Notistack, Iconify.
|
||||
|
||||
## Versioning & Distribution
|
||||
|
||||
- **All releases use SemVer.** ArtifactHub requires SemVer for Headlamp plugin packages — no CalVer, no custom schemes.
|
||||
- **Plugin distribution is ArtifactHub only.** Plugins are installed through Headlamp's native plugin installer sourced from ArtifactHub. No Helm charts, install scripts, or custom install mechanisms.
|
||||
- **Container images go to `ghcr.io` only.** Never Docker Hub, never mirror public images, never reference any other registry.
|
||||
|
||||
## Dependency Management
|
||||
|
||||
- **Dependency updates are owned by Mend Renovate.** Never enable Dependabot, never create `.github/dependabot.yml`, never reference Dependabot in workflows or docs.
|
||||
- **No package mirrors.** Never set up, configure, or reference package mirrors or proxies (npm, pip, Maven, container, etc.). Always use upstream registries directly.
|
||||
- **Security scanning uses local tools.** Run `npm audit` or `pnpm audit` for vulnerability scanning. Do not use the GitHub vulnerability alerts API.
|
||||
@@ -1,119 +0,0 @@
|
||||
---
|
||||
name: product-context
|
||||
description: >
|
||||
Product context for Privileged Escalation. Covers current plugin portfolio,
|
||||
target users, competitive landscape, plugin evaluation framework, and feature
|
||||
spec template.
|
||||
---
|
||||
|
||||
# Product Context
|
||||
|
||||
Load this section when triaging feature requests, evaluating new plugin proposals, or writing specs.
|
||||
|
||||
## Current plugin portfolio
|
||||
|
||||
| Plugin | Repo | What it does | Status |
|
||||
| ------------------ | -------------------------------- | ----------------------------------------------- | ------ |
|
||||
| **Polaris** | `headlamp-polaris-plugin` | Kubernetes best practice validation and scoring | Active |
|
||||
| **Kube-VIP** | `headlamp-kube-vip-plugin` | Kube-VIP load balancer management | Active |
|
||||
| **Rook/Ceph** | `headlamp-rook-plugin` | Rook-Ceph storage cluster monitoring | Active |
|
||||
| **Sealed Secrets** | `headlamp-sealed-secrets-plugin` | Bitnami Sealed Secrets management | Active |
|
||||
| **Intel GPU** | `headlamp-intel-gpu-plugin` | Intel GPU device plugin monitoring | Active |
|
||||
| **TrueNAS CSI** | `headlamp-tns-csi-plugin` | TrueNAS SCALE CSI driver monitoring | Active |
|
||||
| **Argo CD** | `headlamp-argocd-plugin` | Argo CD application delivery management | Active |
|
||||
|
||||
All plugins distributed via **ArtifactHub**, installed through Headlamp's native plugin installer only.
|
||||
|
||||
## Target users
|
||||
|
||||
**Primary: The Platform Engineer**
|
||||
|
||||
* Manages 1-50 Kubernetes clusters, mid-size company (100-2000 employees)
|
||||
* Pain point: "I have 15 tools open to monitor my clusters. I want one dashboard that shows me everything."
|
||||
* Very high tech comfort. Knows Kubernetes deeply. Will read your source code.
|
||||
* Will adopt a plugin in 5 minutes if it solves a real problem. Will drop it in 5 seconds if it's buggy or doesn't add value over `kubectl`.
|
||||
|
||||
**Secondary: The DevOps Lead / SRE Manager**
|
||||
|
||||
* Manages a platform team, responsible for cluster health and reliability.
|
||||
* Wants plugins that visualize what matters and surface problems proactively — NOT another monitoring tool.
|
||||
|
||||
**Anti-persona: The Application Developer**
|
||||
|
||||
App developers care about their deployments, not the cluster. Features like "show me my pod logs" are already in Headlamp core. Don't build for them.
|
||||
|
||||
## Scope
|
||||
|
||||
**In scope**
|
||||
|
||||
* Headlamp plugins that visualize and manage specific Kubernetes ecosystem tools
|
||||
* Plugins that surface operational insights not available in Headlamp core
|
||||
* Plugins for CNCF projects and widely-adopted K8s ecosystem tools
|
||||
* ArtifactHub packaging and distribution
|
||||
|
||||
**Explicitly out of scope**
|
||||
|
||||
* Plugins that duplicate Headlamp core functionality
|
||||
* Non-Kubernetes tools
|
||||
* Hosted/SaaS versions of plugins
|
||||
* Helm-based or sidecar-based plugin installation
|
||||
* Custom Headlamp forks
|
||||
* Monitoring/alerting backends (we visualize, we don't collect metrics)
|
||||
* Multi-cluster management
|
||||
* CLI tools
|
||||
|
||||
## Competitive landscape
|
||||
|
||||
| Competitor | Where PRI differs |
|
||||
| -------------------------------- | ----------------------------------------------------------------------------------- |
|
||||
| **Headlamp core** | We extend it, not compete. If a feature belongs in core, contribute upstream. |
|
||||
| **Lens** | Heavy, desktop-only, commercial. We make web-based, open source Headlamp better. |
|
||||
| **k9s** | Different modality (TUI vs web). Not competitive. |
|
||||
| **Komodor / Kubecost / Robusta** | Standalone products. Our plugins bring their insights INTO Headlamp. Complementary. |
|
||||
|
||||
PRI's moat: leading third-party Headlamp plugin developer. Plugins are free, open source, on ArtifactHub.
|
||||
|
||||
## Plugin evaluation framework
|
||||
|
||||
1. **Is there a widely-adopted K8s ecosystem tool that lacks Headlamp visibility?**
|
||||
* Fewer than 1,000 GitHub stars or in alpha → too early. Close with "revisit when more mature."
|
||||
* Already has a Headlamp plugin → duplicate. Close.
|
||||
2. **Does the plugin add value over `kubectl` + the tool's own CLI/UI?**
|
||||
* "It shows the same thing but in Headlamp" → weak value prop. Good plugins correlate data, surface problems proactively, simplify complex operations.
|
||||
3. **Can Gandalf build and maintain it?**
|
||||
* One engineer can maintain ~6-8 plugins at current complexity. We're at 7 now. New plugins mean either dropping an existing one or hiring.
|
||||
4. **Is it installable via ArtifactHub without extras?**
|
||||
* Plugin requires CRDs/RBAC/cluster resources installed separately → degraded experience.
|
||||
* Unacceptable: plugin requires its own operator or sidecar.
|
||||
|
||||
**Priority tiers**
|
||||
|
||||
* **P0**: Bugs in existing plugins that break functionality or produce incorrect data
|
||||
* **P1**: Enhancements to existing plugins users are requesting
|
||||
* **P2**: New plugins for high-value K8s tools with clear user demand
|
||||
* **P3**: Speculative plugins, cross-plugin features, UX experiments
|
||||
|
||||
## Feature spec template
|
||||
|
||||
```markdown
|
||||
## Problem
|
||||
What operational visibility or capability is missing? Who needs it? What do they do today instead?
|
||||
|
||||
## Proposed Solution
|
||||
What should the plugin show or enable that isn't available today?
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Plugin displays...
|
||||
- [ ] User can...
|
||||
- [ ] Data is accurate when compared to `kubectl` / native CLI output
|
||||
- [ ] Works with [tool name] version X.Y+
|
||||
- [ ] Installable via ArtifactHub without additional cluster-level setup
|
||||
- [ ] Has unit tests covering core display logic
|
||||
|
||||
## Out of Scope for This Issue
|
||||
## Dependencies
|
||||
What must exist in the cluster for this plugin to work? (CRDs, operators, RBAC)
|
||||
|
||||
## Priority
|
||||
P0/P1/P2/P3 with one-sentence justification.
|
||||
```
|
||||
@@ -1,38 +0,0 @@
|
||||
---
|
||||
name: safety
|
||||
description: >
|
||||
Non-negotiable safety rules for all agents at Privileged Escalation. Covers
|
||||
secret handling, destructive command restrictions, sealed-secrets workflow,
|
||||
anti-impersonation rules, role-boundary rules for GitHub actions, and
|
||||
escalation protocol when uncertain.
|
||||
---
|
||||
|
||||
# Safety Considerations
|
||||
|
||||
The following rules apply to all agents at Privileged Escalation without exception.
|
||||
|
||||
## Non-Negotiable Rules
|
||||
|
||||
* **Never exfiltrate secrets or private data.** This includes API keys, tokens, PEM files, database credentials, kubeconfig contents, and any value sourced from a secret reference in your adapter config. Do not log, comment, or return these values in any output.
|
||||
|
||||
* **Seek Board Approval for Destructive Actions.** Destructive means: deleting resources, dropping tables, wiping namespaces, force-pushing branches, resetting git history, removing secrets, or any operation that cannot be undone without restoring from backup.
|
||||
|
||||
* **No plaintext secrets in any repository.** Kubernetes secrets go through Bitnami Sealed Secrets (`kubeseal`). Application credentials go in environment variables injected at runtime — never hardcoded.
|
||||
|
||||
* **Do not use `kubectl create` in production.**
|
||||
The `privilegedescalation` namespace is Flux-managed. Secret changes go through the SealedSecrets workflow, committed to `privilegedescalation/infra`.
|
||||
|
||||
* **Never impersonate another agent or human.** Agents must never sign, attribute, or present GitHub comments, PR reviews, or any external communications as another agent. Every comment must accurately identify the authoring agent. Signing as another agent — even when forwarding their work — is a process violation.
|
||||
|
||||
* **Post GitHub comments only within your defined SDLC role.** An agent must not post a review type that belongs to another role, even if that role's agent has not yet completed its review:
|
||||
- **Engineer bot** posts: implementation comments, CI results
|
||||
- **QA bot** posts: QA reviews
|
||||
- **UAT bot** posts: UAT reviews
|
||||
- **CTO bot** posts: CTO reviews and approvals
|
||||
- **CEO bot** posts: merge confirmations only
|
||||
|
||||
* **Never change another agent's model configuration.** No agent may suggest, request, or execute a change to any other agent's model settings — including for quota exhaustion, cost optimization, or any other reason. Quota issues must be escalated to the board. This is a non-negotiable board directive.
|
||||
|
||||
## If you are unsure
|
||||
|
||||
If you are unsure whether an action is safe, stop. Post a comment on the Paperclip issue explaining what you are about to do and why you are uncertain, set the issue to `blocked`, and escalate to your manager. Do not guess.
|
||||
@@ -1,181 +0,0 @@
|
||||
---
|
||||
name: sdlc
|
||||
description: >
|
||||
Software development lifecycle rules for Privileged Escalation. Covers GitHub
|
||||
issue approval gates, authentication, branch strategy, PR review policy,
|
||||
pipeline stages, CI/CD, and security review.
|
||||
---
|
||||
|
||||
# Software Development Lifecycle
|
||||
|
||||
## GitHub Authentication
|
||||
|
||||
Access to GitHub is done via token in your env **Never** run `gh auth login` directly — it hangs headless agents.
|
||||
|
||||
## GitHub Issues — Board Approval Required
|
||||
|
||||
**If a task originated from GitHub (`originKind: "github"` in the issue data), do not begin any work.** Immediately create a `request_board_approval`:
|
||||
|
||||
```json
|
||||
POST /api/companies/{companyId}/approvals
|
||||
{
|
||||
"type": "request_board_approval",
|
||||
"requestedByAgentId": "{your-agent-id}",
|
||||
"issueIds": ["{issue-id}"],
|
||||
"payload": {
|
||||
"title": "Board approval required: GitHub issue",
|
||||
"summary": "Summarize what the GitHub issue requests.",
|
||||
"recommendedAction": "Approve to begin work.",
|
||||
"risks": ["Work begins without board review if approved."]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Set the issue to `blocked` until `PAPERCLIP_APPROVAL_STATUS` confirms approval. Only proceed once approved.
|
||||
|
||||
## Branch Strategy
|
||||
|
||||
All plugin repositories use three long-lived branches representing a promotion chain:
|
||||
|
||||
| Branch | Environment | Owner | Who merges to it |
|
||||
|--------|-------------|-------|-----------------|
|
||||
| `dev` | Development | Engineer | Engineer self-merges after CI passes |
|
||||
| `uat` | User Acceptance Testing | QA (Regression Regina) | QA merges after code review |
|
||||
| `main` | Production | UAT (Pixel Patty) | UAT merges after browser validation |
|
||||
|
||||
**Engineers target `dev` via feature branches** — never push directly to any long-lived branch.
|
||||
|
||||
Feature branches follow the convention: `<agent-name>/<short-description>` (e.g., `gandalf/add-sealed-secrets-list`).
|
||||
|
||||
## Pull Requests
|
||||
|
||||
All changes must happen via pull request. Always include `cc @cpfarhood` at the bottom of the PR body for visibility — not as a reviewer.
|
||||
|
||||
```bash
|
||||
gh pr create --title "..." --body "... cc @cpfarhood"
|
||||
```
|
||||
|
||||
## PR Review & Merge Policy
|
||||
|
||||
**Do not approve a PR with failing tests, type errors, or no coverage for new code.**
|
||||
|
||||
### Promotion chain
|
||||
|
||||
Each promotion is a PR reviewed and merged by its gate owner:
|
||||
|
||||
1. **feature → dev** — Engineer self-merges after CI passes. No review required. Dev is for validation, not quality gates.
|
||||
2. **dev → uat** — QA (Regression Regina) reviews code quality: test coverage, regressions, edge cases. QA merges to `uat` after approval.
|
||||
3. **uat → main** — UAT (Pixel Patty) validates the deployed application via Playwright browser testing. UAT merges to `main` after validation passes. For detailed UAT testing procedures, see the `uat` company skill.
|
||||
|
||||
**Each gate owner has merge authority.** No separate merge step by another role. No agent merges their own code to `uat` or `main` — only the gate owner merges promotions they review.
|
||||
|
||||
## Pipeline
|
||||
|
||||
### Pipeline A: Plugin/Feature Changes
|
||||
|
||||
```text
|
||||
Engineer → PR to dev → self-merge → deploys to dev
|
||||
→ Engineer validates on dev
|
||||
→ PR from dev → uat → QA reviews → QA merges
|
||||
→ Deploys to UAT environment
|
||||
→ PR from uat → main → UAT validates → UAT merges
|
||||
→ Production
|
||||
```
|
||||
|
||||
Applies to changes in `headlamp-*-plugin/` repos (plugin code, features, bug fixes).
|
||||
|
||||
**UAT_PLAYBOOK.md maintenance:** When modifying a plugin in any way that changes how it must be tested — including new features, changed behavior, updated UI flows, or different data sources — the engineer must update the `UAT_PLAYBOOK.md` file in the plugin repository root with the current testing steps before requesting UAT. This ensures the playbook stays current as plugins evolve and UAT agents have accurate test guidance.
|
||||
|
||||
### Pipeline B: Infrastructure Changes (No UI Impact)
|
||||
|
||||
```text
|
||||
Engineer → PR to main → CI passes → QA reviews → QA merges
|
||||
→ Production
|
||||
```
|
||||
|
||||
Applies to changes in `.github/workflows/`, `infra/`, `org/` repos, and template repos. No UAT stage needed — infrastructure changes have no UI to validate.
|
||||
|
||||
**Detection:** If `git diff` shows changes only in `.github/`, `infra/`, `org/`, or deployment files → Pipeline B. If any `headlamp-*-plugin/` code changed → Pipeline A.
|
||||
|
||||
**Failure routing:** Any stage failure returns directly to the engineer via PR comments.
|
||||
|
||||
## Issue Reviewers and Approvers
|
||||
|
||||
Every Paperclip issue has **Reviewers** and **Approvers** fields visible in the UI sidebar. These are populated by setting `executionPolicy` when creating the issue. Without an execution policy, those fields show "None" and handoffs never trigger.
|
||||
|
||||
**All stage and participant `id` fields must be random UUIDs.** Generate them at issue-creation time (e.g. via `uuidgen` or your language's UUID library). Do not use descriptive strings — the API rejects non-UUID values.
|
||||
|
||||
### Pipeline A — set reviewers on issue creation
|
||||
|
||||
For plugin/feature work (Pipeline A), set a two-stage execution policy so QA and UAT appear as reviewers:
|
||||
|
||||
```bash
|
||||
QA_STAGE_ID=$(uuidgen)
|
||||
QA_PART_ID=$(uuidgen)
|
||||
UAT_STAGE_ID=$(uuidgen)
|
||||
UAT_PART_ID=$(uuidgen)
|
||||
```
|
||||
|
||||
```json
|
||||
"executionPolicy": {
|
||||
"mode": "normal",
|
||||
"commentRequired": true,
|
||||
"stages": [
|
||||
{
|
||||
"id": "<QA_STAGE_ID>",
|
||||
"type": "review",
|
||||
"approvalsNeeded": 1,
|
||||
"participants": [
|
||||
{ "id": "<QA_PART_ID>", "type": "agent", "agentId": "fd5dbec8-ddbb-4b57-9703-624e0ed90053" }
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "<UAT_STAGE_ID>",
|
||||
"type": "review",
|
||||
"approvalsNeeded": 1,
|
||||
"participants": [
|
||||
{ "id": "<UAT_PART_ID>", "type": "agent", "agentId": "01ec02f7-70c2-4fa1-ac3f-2545f1237ac3" }
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
- Stage 1 reviewer: Regression Regina (`fd5dbec8-ddbb-4b57-9703-624e0ed90053`)
|
||||
- Stage 2 reviewer: Pixel Patty (`01ec02f7-70c2-4fa1-ac3f-2545f1237ac3`)
|
||||
|
||||
### Pipeline B — single reviewer
|
||||
|
||||
For infrastructure changes (Pipeline B), use one QA review stage:
|
||||
|
||||
```json
|
||||
"executionPolicy": {
|
||||
"mode": "normal",
|
||||
"commentRequired": true,
|
||||
"stages": [
|
||||
{
|
||||
"id": "<QA_STAGE_ID>",
|
||||
"type": "review",
|
||||
"approvalsNeeded": 1,
|
||||
"participants": [
|
||||
{ "id": "<QA_PART_ID>", "type": "agent", "agentId": "fd5dbec8-ddbb-4b57-9703-624e0ed90053" }
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Triggering the handoff
|
||||
|
||||
When an engineer completes work and merges to `dev`, set the Paperclip issue status to `in_review`. This activates the execution policy and wakes the first reviewer. Each reviewer approves or requests changes through the normal Paperclip issue update flow — see the Paperclip skill's `references/api-reference.md` for details.
|
||||
|
||||
## CI/CD
|
||||
|
||||
- CI runs on self-hosted ARC runners: `runs-on: runners-privilegedescalation`
|
||||
- CI triggers on PRs to `dev`, `uat`, and `main` branches
|
||||
- Engineers may modify `.github/workflows/` files directly via PR
|
||||
- Runners scale to zero when idle and start automatically when a workflow triggers
|
||||
|
||||
## Security Review
|
||||
|
||||
Security review is handled as part of the QA review stage. Regression Regina evaluates security concerns during her code quality review. There is no separate dedicated security review agent.
|
||||
@@ -1,134 +0,0 @@
|
||||
# SDLC Pipeline Diagram
|
||||
|
||||
## Full Lifecycle
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
subgraph Origin["Task Origin"]
|
||||
GH["GitHub Issue"]
|
||||
PP["Paperclip Issue"]
|
||||
end
|
||||
|
||||
subgraph Approval["Board Gate"]
|
||||
BA{"Board Approval<br/>Required?"}
|
||||
REQ["Request Board Approval<br/>→ Issue blocked"]
|
||||
APPROVED["Approved"]
|
||||
end
|
||||
|
||||
subgraph Detection["Pipeline Detection"]
|
||||
DET{"Changed files?"}
|
||||
PA["Pipeline A<br/>Plugin / Feature"]
|
||||
PB["Pipeline B<br/>Infrastructure"]
|
||||
end
|
||||
|
||||
subgraph PipelineA["Pipeline A: Plugin / Feature Changes"]
|
||||
direction TB
|
||||
A_ENG["Engineer writes code<br/>(Gandalf)"]
|
||||
A_PR_DEV["PR → dev<br/>Engineer self-merges"]
|
||||
A_CI_DEV{"CI Passes?"}
|
||||
A_DEV["Deploys to dev<br/>Engineer validates"]
|
||||
A_PR_UAT["PR dev → uat"]
|
||||
A_QA["QA Review<br/>(Regression Regina)<br/>Code quality, test coverage"]
|
||||
A_QA_PASS{"QA Approved?"}
|
||||
A_QA_MERGE["QA merges to uat"]
|
||||
A_UAT_DEPLOY["Deploys to UAT env"]
|
||||
A_PR_MAIN["PR uat → main"]
|
||||
A_UAT["UAT Review<br/>(Pixel Patty)<br/>Playwright browser validation"]
|
||||
A_UAT_PASS{"UAT Approved?"}
|
||||
A_UAT_MERGE["UAT merges to main"]
|
||||
end
|
||||
|
||||
subgraph PipelineB["Pipeline B: Infrastructure Changes"]
|
||||
direction TB
|
||||
B_ENG["Engineer writes code<br/>(Gandalf / Hugh)"]
|
||||
B_PR["PR → main"]
|
||||
B_CI{"CI Passes?"}
|
||||
B_QA["QA Review<br/>(Regression Regina)"]
|
||||
B_QA_PASS{"QA Approved?"}
|
||||
B_QA_MERGE["QA merges to main"]
|
||||
end
|
||||
|
||||
subgraph Result["Outcome"]
|
||||
PROD["Merged to main<br/>✓ Production"]
|
||||
RETURNED["Returned to Engineer<br/>Fix and resubmit"]
|
||||
end
|
||||
|
||||
%% Origin routing
|
||||
GH --> BA
|
||||
PP --> DET
|
||||
BA -->|"originKind: github"| REQ
|
||||
REQ -->|"PAPERCLIP_APPROVAL_STATUS"| APPROVED
|
||||
BA -->|"originKind: other"| DET
|
||||
APPROVED --> DET
|
||||
|
||||
%% Pipeline detection
|
||||
DET -->|"headlamp-*-plugin/ code"| PA
|
||||
DET -->|".github/, infra/, org/"| PB
|
||||
|
||||
%% Pipeline A flow
|
||||
PA --> A_ENG --> A_PR_DEV --> A_CI_DEV
|
||||
A_CI_DEV -->|"Pass"| A_DEV
|
||||
A_CI_DEV -->|"Fail"| RETURNED
|
||||
A_DEV --> A_PR_UAT --> A_QA --> A_QA_PASS
|
||||
A_QA_PASS -->|"Approved"| A_QA_MERGE --> A_UAT_DEPLOY
|
||||
A_QA_PASS -->|"Changes requested"| RETURNED
|
||||
A_UAT_DEPLOY --> A_PR_MAIN --> A_UAT --> A_UAT_PASS
|
||||
A_UAT_PASS -->|"Approved"| A_UAT_MERGE --> PROD
|
||||
A_UAT_PASS -->|"Changes requested"| RETURNED
|
||||
|
||||
%% Pipeline B flow
|
||||
PB --> B_ENG --> B_PR --> B_CI
|
||||
B_CI -->|"Pass"| B_QA --> B_QA_PASS
|
||||
B_CI -->|"Fail"| RETURNED
|
||||
B_QA_PASS -->|"Approved"| B_QA_MERGE --> PROD
|
||||
B_QA_PASS -->|"Changes requested"| RETURNED
|
||||
|
||||
RETURNED -->|"Fix and resubmit"| A_PR_DEV
|
||||
RETURNED -->|"Fix and resubmit"| B_PR
|
||||
|
||||
%% Styling
|
||||
classDef gate fill:#f9e4e4,stroke:#c0392b,color:#000
|
||||
classDef pass fill:#e4f9e4,stroke:#27ae60,color:#000
|
||||
classDef agent fill:#e4e9f9,stroke:#2980b9,color:#000
|
||||
classDef decision fill:#fef9e7,stroke:#f39c12,color:#000
|
||||
classDef deploy fill:#e8f4f8,stroke:#2c3e50,color:#000
|
||||
|
||||
class BA,A_CI_DEV,A_QA_PASS,A_UAT_PASS,B_CI,B_QA_PASS,DET decision
|
||||
class A_QA,A_UAT,B_QA gate
|
||||
class PROD pass
|
||||
class A_ENG,B_ENG agent
|
||||
class A_DEV,A_UAT_DEPLOY deploy
|
||||
```
|
||||
|
||||
## Branch Promotion Chain
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph Feature["Feature Branch"]
|
||||
FB["gandalf/feature-name"]
|
||||
end
|
||||
|
||||
subgraph Dev["dev branch"]
|
||||
DEV["Engineer self-merges<br/>Deploys to dev env"]
|
||||
end
|
||||
|
||||
subgraph UAT["uat branch"]
|
||||
UATB["QA reviews & merges<br/>Deploys to UAT env"]
|
||||
end
|
||||
|
||||
subgraph Main["main branch"]
|
||||
MAIN["UAT validates & merges<br/>Deploys to production"]
|
||||
end
|
||||
|
||||
FB -->|"PR + CI"| DEV
|
||||
DEV -->|"PR + QA review"| UATB
|
||||
UATB -->|"PR + UAT review"| MAIN
|
||||
|
||||
classDef dev fill:#fff3cd,stroke:#856404,color:#000
|
||||
classDef uat fill:#cce5ff,stroke:#004085,color:#000
|
||||
classDef prod fill:#d4edda,stroke:#155724,color:#000
|
||||
|
||||
class DEV dev
|
||||
class UATB uat
|
||||
class MAIN prod
|
||||
```
|
||||
@@ -1,69 +0,0 @@
|
||||
---
|
||||
name: uat
|
||||
description: >
|
||||
Functional UAT procedures for Privileged Escalation Headlamp plugins. General
|
||||
behavior, acceptance criteria, artifact requirements, and reference to
|
||||
plugin-specific test steps in UAT_PLAYBOOK.md.
|
||||
---
|
||||
|
||||
# UAT Procedures
|
||||
|
||||
## Purpose
|
||||
|
||||
This skill defines **functional User Acceptance Testing** for all Privileged Escalation Headlamp plugins. UAT validates that plugins work correctly in the deployed environment — by exercising plugin features in a running Headlamp instance, not by reviewing code or CI results.
|
||||
|
||||
## UAT Environment
|
||||
|
||||
The UAT Headlamp instance runs in the `headlamp-uat` Kubernetes namespace. Navigate to the Headlamp UAT URL using your Playwright browser. The plugin under test must be deployed to UAT before testing begins.
|
||||
|
||||
## General Process
|
||||
|
||||
For every `uat→main` promotion:
|
||||
|
||||
1. Open the Headlamp UAT instance in the browser
|
||||
2. Confirm the plugin appears in the sidebar or app bar
|
||||
3. Read the plugin's `UAT_PLAYBOOK.md` for the specific test steps to run
|
||||
4. Execute the test steps from the playbook, capturing screenshots at each verification
|
||||
5. Check the browser console for errors throughout
|
||||
6. Post a structured test report (see Artifacts section)
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
A plugin passes UAT when:
|
||||
|
||||
- **Plugin loads** — sidebar entry or app bar action is visible and accessible
|
||||
- **Features work** — all core features in the playbook execute without errors
|
||||
- **No console errors** — browser console shows no errors during normal operation
|
||||
- **Data matches cluster state** — plugin data is consistent with `kubectl` queries against the cluster
|
||||
|
||||
A plugin fails UAT when:
|
||||
|
||||
- Plugin does not load or renders only an error state
|
||||
- Any core feature is inaccessible or produces errors
|
||||
- Console errors are present and not explainable as unrelated noise
|
||||
- Displayed data contradicts known cluster state
|
||||
|
||||
## Artifact Requirements
|
||||
|
||||
For each plugin tested, the UAT report must include:
|
||||
|
||||
1. **Screenshots** of the plugin running in Headlamp — sidebar entry visible, main view loaded, at least one detail view
|
||||
2. **Test checklist** — each step from `UAT_PLAYBOOK.md` marked pass/fail
|
||||
3. **Console errors** — any browser console errors observed (attach screenshot if present)
|
||||
4. **Environment info** — Headlamp version, plugin version, browser used, namespace context
|
||||
|
||||
## Reading UAT_PLAYBOOK.md
|
||||
|
||||
Each plugin repository contains a `UAT_PLAYBOOK.md` in its root directory. That file contains the canonical test steps for that specific plugin. Before running UAT, read the relevant playbook to know:
|
||||
|
||||
- Which features to exercise
|
||||
- What the expected results are
|
||||
- What screenshots to capture at each step
|
||||
|
||||
If `UAT_PLAYBOOK.md` does not exist for a plugin, treat that as a gap — report it in the UAT findings and flag it as a documentation issue.
|
||||
|
||||
## Decision Criteria
|
||||
|
||||
- **Approve** the `uat→main` promotion when all applicable test steps from the playbook pass and no console errors are present
|
||||
- **Request changes** when any test step fails — include specific failing steps, observed results vs. expected results, and failure screenshots
|
||||
- **Block** if the plugin fails to load entirely — escalate to CTO as a deployment issue requiring immediate resolution
|
||||
@@ -0,0 +1,85 @@
|
||||
# Social Media Batch - 2026-03-07
|
||||
|
||||
## Strategic Summary
|
||||
|
||||
First-ever social batch for Privileged Escalation. The org has 6 Headlamp plugins across storage, security, and infrastructure -- all freshly released, all at zero stars. The play here is name recognition and curiosity: make people encounter "Privileged Escalation" in their feed and wonder what it is before they click. Leading with the sealed-secrets plugin (client-side crypto angle) and the absurdity of launching 6 plugins to zero fanfare.
|
||||
|
||||
---
|
||||
|
||||
## 1. Ready to Post
|
||||
|
||||
### Post 1
|
||||
|
||||
**Platform**: Twitter/X
|
||||
**Post**:
|
||||
We shipped 6 Kubernetes Headlamp plugins and nobody noticed.
|
||||
|
||||
Storage benchmarking, Rook-Ceph visibility, Polaris auditing, Sealed Secrets with actual client-side encryption, Intel GPU monitoring, and kube-vip dashboards.
|
||||
|
||||
Zero stars across the board. We are crushing it.
|
||||
|
||||
github.com/privilegedescalation
|
||||
**CMO Note**: Self-deprecating launch acknowledgment. The honesty about zero stars is the hook -- it reads as human, not corporate. Links to the org for curious clicks.
|
||||
|
||||
---
|
||||
|
||||
### Post 2
|
||||
|
||||
**Platform**: Bluesky
|
||||
**Post**:
|
||||
the sealed secrets headlamp plugin does client-side RSA-OAEP + AES-256-GCM encryption so your plaintext never leaves the browser.
|
||||
|
||||
someone forked it last month. we have our first user. or our first person who accidentally clicked fork. either way, we are celebrating.
|
||||
**CMO Note**: Technical specificity makes it credible. The fork joke (sm-moshi, Feb 22) is real and plays well on Bluesky's irony-friendly audience. Seeds curiosity about what Headlamp plugins are.
|
||||
|
||||
---
|
||||
|
||||
### Post 3
|
||||
|
||||
**Platform**: Mastodon
|
||||
**Post**:
|
||||
Genuine question for the fediverse: if you have 6 open source projects and zero stars on any of them, are you a software company or just a guy with a lot of repos?
|
||||
|
||||
Asking for a friend. The friend is github.com/privilegedescalation.
|
||||
**CMO Note**: Mastodon audience appreciates self-aware humor. This is pure slow-burn -- raises the question of what Privileged Escalation is without explaining it. The link is there for anyone curious enough to click.
|
||||
|
||||
---
|
||||
|
||||
## 2. Risky but Worth Discussing
|
||||
|
||||
### Post 4
|
||||
|
||||
**Platform**: Twitter/X
|
||||
**Post**:
|
||||
Every Kubernetes UI either costs money or looks like it was designed during a mass layoff event.
|
||||
|
||||
We've been building Headlamp plugins that make the free one actually useful. Rook-Ceph dashboards, Polaris auditing, storage benchmarks -- the stuff you duct-tape together with kubectl and regret.
|
||||
|
||||
github.com/privilegedescalation
|
||||
**CMO Note**: Mildly spicy take on the K8s UI landscape. Does not name competitors directly but the implication is clear. Could rub Lens/Rancher people the wrong way. Worth discussing tone.
|
||||
|
||||
---
|
||||
|
||||
## 3. Backlog (Evergreen)
|
||||
|
||||
### Post 5
|
||||
|
||||
**Platform**: LinkedIn
|
||||
**Post**:
|
||||
We just audited our own GitHub repos and found that 4 out of 6 were missing LICENSE files.
|
||||
|
||||
They all had Apache-2.0 badges in the README. The actual license text? Not present. Technically, anyone using our code was operating on vibes and good faith.
|
||||
|
||||
Fixed now. But if your open source project has a license badge and no LICENSE file, maybe go check. We'll wait.
|
||||
**CMO Note**: Honest product personality at work. Admitting a real flaw (that we just fixed) builds trust and is genuinely useful advice. LinkedIn audience will share practical open source governance content.
|
||||
|
||||
---
|
||||
|
||||
### Post 6
|
||||
|
||||
**Platform**: Twitter/X
|
||||
**Post**:
|
||||
TIL "Privileged Escalation" as a GitHub org name gets flagged by approximately zero security scanners.
|
||||
|
||||
We checked.
|
||||
**CMO Note**: Pure name recognition play. The org name is inherently memorable and slightly provocative -- leaning into that. Short enough for easy engagement.
|
||||
Reference in New Issue
Block a user