diff --git a/docs/appendix-j-cloud-editors.md b/docs/appendix-j-cloud-editors.md index 2853564d..4210f152 100644 --- a/docs/appendix-j-cloud-editors.md +++ b/docs/appendix-j-cloud-editors.md @@ -348,6 +348,18 @@ If the branch exists on GitHub, you can create a new Codespace from it. Uncommit You may have committed but not pushed. In the Source Control panel, look for the **Sync Changes** or **Push** button. Run `git push` in the terminal if needed. +### Commit and Push is disabled in github.dev even though I have write access + +In github.dev, your edits are saved in the browser's local storage until you commit them. If the repository receives new commits after you opened the editor (for example, workshop maintenance updates pushed to your Learning Room), the editor's copy of the repository goes stale and **Commit & Push** can become disabled - pressing `Ctrl+Enter` in the commit message field does nothing, and the Accessible View reports that commit and push are disabled. AI assistants sometimes misreport this as a permissions problem; if you could open the private repository in github.dev, you are signed in and your access is fine. + +To fix it: + +1. Reload the browser tab (`F5`), or go back to the repository page on GitHub.com and press `.` to reopen github.dev. Your uncommitted edits are restored from browser storage after the reload. +2. Confirm you are signed in: the **Accounts** button in the Activity Bar should announce your GitHub username. +3. Return to the Source Control panel (`Ctrl+Shift+G`), enter your commit message, and press `Ctrl+Enter`. + +If it is still disabled after a reload, copy your edited text to the clipboard as a backup, then use the **Edit this file** (pencil) editor on GitHub.com instead - it commits directly and does not depend on browser state. + --- *Next: [Appendix K: Copilot Reference](appendix-k-copilot-reference.md)* diff --git a/html/docs/appendix-j-cloud-editors.html b/html/docs/appendix-j-cloud-editors.html index 77b1a16c..ee5a14ed 100644 --- a/html/docs/appendix-j-cloud-editors.html +++ b/html/docs/appendix-j-cloud-editors.html @@ -267,6 +267,7 @@

On This Page

  • Extensions I rely on locally are not available
  • I accidentally deleted my Codespace before pushing
  • My changes are not showing in GitHub after committing
    • +
  • Commit and Push is disabled in github.dev even though I have write access
  • Authoritative Sources
  • Section-Level Source Map
    • @@ -723,6 +724,15 @@

    I accidentally delet

    If the branch exists on GitHub, you can create a new Codespace from it. Uncommitted changes in a deleted Codespace cannot be recovered.

    My changes are not showing in GitHub after committing

    You may have committed but not pushed. In the Source Control panel, look for the Sync Changes or Push button. Run git push in the terminal if needed.

    +

    Commit and Push is disabled in github.dev even though I have write access

    +

    In github.dev, your edits are saved in the browser's local storage until you commit them. If the repository receives new commits after you opened the editor (for example, workshop maintenance updates pushed to your Learning Room), the editor's copy of the repository goes stale and Commit & Push can become disabled - pressing Ctrl+Enter in the commit message field does nothing, and the Accessible View reports that commit and push are disabled. AI assistants sometimes misreport this as a permissions problem; if you could open the private repository in github.dev, you are signed in and your access is fine.

    +

    To fix it:

    +
      +
    1. Reload the browser tab (F5), or go back to the repository page on GitHub.com and press . to reopen github.dev. Your uncommitted edits are restored from browser storage after the reload.
      2. +
    2. Confirm you are signed in: the Accounts button in the Activity Bar should announce your GitHub username.
      3. +
    3. Return to the Source Control panel (Ctrl+Shift+G), enter your commit message, and press Ctrl+Enter.
      4. +
    +

    If it is still disabled after a reload, copy your edited text to the clipboard as a backup, then use the Edit this file (pencil) editor on GitHub.com instead - it commits directly and does not depend on browser state.

    Next: Appendix K: Copilot Reference
    Back: Appendix I: GitHub CLI Reference
    Teaching chapter: Chapter 01: Choose Your Tools

    Authoritative Sources

    diff --git a/html/search-index.json b/html/search-index.json index 8a0c201a..0ab64273 100644 --- a/html/search-index.json +++ b/html/search-index.json @@ -353,12 +353,6 @@ "url": "docs/appendix-i-github-cli.html", "body": "Appendix I: GitHub CLI Reference Episode coming soon: GitHub CLI Reference - a conversational audio overview of this appendix. Listen before reading to preview the concepts, or after to reinforce what you learned. Reference companion to: Chapter 01: Choose Your Tools | Also relevant: Chapter 14 Authoritative source: GitHub CLI Manual | GitHub Accessibility Lab: CLI Guide Your Terminal, Supercharged for GitHub Who this is for: You want to manage GitHub — issues, pull requests, repos, releases — from your terminal without opening a browser. The GitHub CLI ( gh ) gives you full access to GitHub from the command line, with clean plain-text output that works beautifully with screen readers. gh handles the GitHub side of things (issues, PRs, repos, releases). git handles the local version control side (commits, branches, history). You use both together. Getting started principles for accessible CLI workflows Follow a local-to-remote progression: learn git basics first, then layer gh workflows. Treat terminal output as the source of truth. Confirm each command result before moving on. Prefer short, reversible steps: clone, inspect, branch, edit, commit, push, open PR. Keep one reliable terminal profile and one reliable editor setup rather than constant tool switching. Use browser fallback strategically for verification, not as a replacement for command understanding. Table of Contents Installing and Authenticating Repos — Clone, Fork, Create, View Issues — Create, List, View, Comment, Close Pull Requests — Create, Review, Merge, Check Releases — Create, List, Upload Search — Issues, PRs, Repos, Code Labels and Milestones Output Formatting — JSON, jq, Templates Aliases — Create Your Own Shortcuts Extensions — Adding New Commands Copilot in the CLI Screen Reader Tips Quick Reference Card 1. Installing and Authenticating Installing Windows winget install GitHub.cli Or download the installer from cli.github.com . macOS brew install gh Linux (Debian/Ubuntu) ( type -p wget >/dev/null || ( sudo apt update && sudo apt-get install wget -y)) \\ && sudo mkdir -p -m 755 /etc/apt/keyrings \\ && wget -qO- https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo tee /etc/apt/keyrings/githubcli-archive-keyring.gpg > /dev/null \\ && sudo chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg \\ && echo "deb [arch= $(dpkg --print-architecture) signed-by=/etc/apt/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null \\ && sudo apt update \\ && sudo apt install gh -y Verify installation gh --version Authenticating gh auth login Follow the prompts: Where do you use GitHub? → GitHub.com (or Enterprise) Preferred protocol? → HTTPS (or SSH) Authenticate with browser? → Yes — your browser opens for OAuth sign-in After signing in, return to the terminal. You're done. # Check your auth status at any time gh auth status # Log out gh auth logout # Refresh credentials / add new scopes gh auth refresh Screen reader tip: gh auth login is an interactive prompt — navigate with Arrow keys, confirm with Enter . All prompts are plain text and read naturally. The browser step opens automatically; switch back to the terminal when the browser confirms success. Command safety guideline: Use options documented in gh --help and the GitHub CLI manual . Avoid undocumented or experimental flags in classroom and production workflows. Windows Terminal setup pattern If you are on Windows, configure Windows Terminal once and reuse it: Keep a dedicated shell profile for your Git workflows. Learn mark mode ( Ctrl+Shift+M ) to review and copy command output line by line. Use command palette ( Ctrl+Shift+P ) to find terminal actions without memorizing every shortcut. Keep your font size and contrast settings stable so output remains readable across sessions. Learning Cards: Getting Started with gh Screen reader users gh auth login uses plain-text arrow-key prompts -- every option is announced as you arrow through the list After authentication, gh auth status confirms your login in a single readable line -- no browser needed All gh output is plain text with no hidden elements, making it one of the most screen-reader-friendly GitHub interfaces Low vision users Increase your terminal font size before running gh commands -- all output scales with your terminal settings Use a high-contrast terminal theme (light text on dark background, or vice versa) for comfortable reading of command output gh output is plain text with no color-dependent meaning -- colors are supplementary labels, not the only indicator Sighted users The interactive prompts use arrow-based selection with a highlight marker -- look for the > indicator next to your current choice After gh auth login , the terminal prints a success confirmation with your username -- verify it matches your GitHub account Install gh via winget" }, - { - "id": "docs/appendix-j-cloud-editors.html", - "title": "Appendix J: GitHub Codespaces", - "url": "docs/appendix-j-cloud-editors.html", - "body": "Appendix J: GitHub Codespaces Listen to Episode 31: GitHub Codespaces - a conversational audio overview of this chapter. Listen before reading to preview the concepts, or after to reinforce what you learned. Reference companion to: Chapter 01: Choose Your Tools | Also relevant: Chapter 11 Authoritative source: GitHub Docs: Codespaces Cloud Development Environments - Accessibility Guide GitHub Codespaces gives you a full VS Code development environment in your browser or connected to your local VS Code, running on a cloud machine. For screen reader users, this means a consistent, pre-configured environment with no local setup required. Table of Contents What Is GitHub Codespaces? Creating a Codespace Codespace Environments Accessibility in Codespaces Screen Reader Configuration Keyboard Shortcuts in Codespaces Managing Your Codespaces Dotfiles and Persistent Configuration Codespaces vs GitHub.dev Common Issues and Workarounds 1. What Is GitHub Codespaces? A Codespace is a cloud-hosted development environment. When you open one, GitHub provisions a virtual machine, clones your repository into it, and connects it to a VS Code interface - either in your browser or via your local VS Code Desktop. Why this matters for accessibility No local installation of tools, compilers, or language runtimes required Your screen reader and OS settings stay on your machine; only the editor runs in the cloud VS Code's full accessibility features (audio cues, screen reader optimized mode, diff viewer) are available The environment is identical for every workshop participant - facilitators can reproduce issues reliably Free tier: GitHub provides a monthly free allowance of Codespace hours for personal accounts. Workshop usage typically falls well within the free tier. Learning Cards: Cloud Editors Overview Screen reader users Codespaces gives you a full VS Code interface with terminal access -- your screen reader and OS settings stay on your local machine The browser-based editor activates screen reader optimized mode automatically if your OS signals a screen reader is running Connect a Codespace to your local VS Code Desktop (via the Codespaces extension) for the most familiar screen reader experience Low vision users Settings Sync carries your font size, theme, and zoom preferences from local VS Code into Codespaces automatically The browser-based editor supports Ctrl+= / Ctrl+- zoom just like desktop VS Code Use a high-contrast VS Code theme -- it applies identically in the cloud editor Sighted users Press . on any GitHub repository page to open it instantly in github.dev (browser editor, no terminal) Codespaces provisions a full VM with terminal -- use it when you need to run code, not just edit The default 2-core machine is sufficient for workshop exercises; upgrade only for heavy builds 2. Creating a Codespace From a Repository Page Navigate to the repository on GitHub Press the Code button (keyboard shortcut: there is no direct shortcut - Tab to the button) In the panel that opens, choose the Codespaces tab Activate Create codespace on main (or your branch name) The Codespace opens in a new browser tab after provisioning (typically 30-60 seconds) From the Codespaces Dashboard Go to github.com/codespaces Activate New codespace Use the search field to find your repository Choose a branch, machine type, and region Activate Create codespace Machine Types Type CPU RAM Best for 2-core 2 vCPU 8 GB General development, documentation 4-core 4 vCPU 16 GB Builds, tests, moderate workloads 8-core 8 vCPU 32 GB Heavy builds, multiple services For workshop exercises, the default 2-core machine is sufficient. 3. Codespace Environments Browser (VS Code for the Web) The Codespace opens directly in your browser as a fully functional VS Code interface. Works in Chrome, Edge, Firefox, and Safari Screen reader support varies slightly by browser - Chrome and Edge have the most consistent behavior with NVDA and JAWS No installation needed Some VS Code extensions are not available in the browser version Local VS Code Desktop If you prefer your local VS Code setup with your extensions and settings: Install the GitHub Codespaces extension in VS Code Sign in to GitHub in VS Code Open the Command Palette ( Ctrl+Shift+P / Cmd+Shift+P ) Run Codespaces: Connect to Codespace Select an existing Codespace or create a new one When connected via local VS Code, your screen reader interacts with your local VS Code installation - all your familiar settings apply. 4. Accessibility in Codespaces Screen Reader Optimized Mode When VS Code detects a screen reader, it automatically activates Screen Reader Optimized mode. You can verify or toggle it manually: Open the Command Palette ( Ctrl+Shift+P ) Search for Toggle Screen Reader Accessibility Mode Press Enter to activate In this mode: The editor reads content line by line instead of character by character Diff views are rendered as accessible text comparisons Inline suggestions from Copilot are announced on a key" - }, { "id": "docs/appendix-k-copilot-reference.html", "title": "Appendix K: Copilot Reference", @@ -485,6 +479,12 @@ "url": "docs/appendix-z-github-skills.html", "body": "Appendix Z: GitHub Skills - Complete Course Catalog Listen to Episode 43: GitHub Skills - Complete Course Catalog - a conversational audio overview of this chapter. Listen before reading to preview the concepts, or after to reinforce what you learned. Reference companion to: Chapter 00: Pre-Workshop Setup | Also relevant: Chapter 22: What Comes Next Authoritative source: GitHub Skills GitHub Skills is GitHub's free, self-paced interactive learning platform. Every course runs entirely inside GitHub - no external site, no separate login, no video. You copy a course repository to your own account, and an automated bot named Mona teaches you through real issues and pull requests. This appendix catalogs every available GitHub Skills module, organized into learning paths that build on the skills you practiced in this workshop. Use it as a roadmap for continued learning after Day 2. Learning Cards: How GitHub Skills Works Screen reader users Every GitHub Skills course runs inside a standard GitHub repository -- the screen reader navigation skills from this workshop (heading nav, issue reading, PR workflows) apply directly After copying a course with "Use this template," navigate to the Issues tab ( G then I ) and press H or 3 to find "Step 1:" -- this is where Mona's first lesson appears Mona posts feedback as issue comments -- press 9 (NVDA/JAWS) to jump to the comments section and read her instructions Low vision users Course content appears as standard GitHub issues and comments -- your existing GitHub theme and font size settings apply automatically Mona's step numbers appear as issue titles with "Step 1:", "Step 2:" prefixes -- scan the Issues list for these numbered titles to track your progress Course completion is indicated when Mona closes the final issue with a success message -- look for the purple "Closed" badge Sighted users Start any course by clicking "Start course" on the module page, then "Use this template" then "Create a new repository" -- Mona activates within 20 seconds Each step appears as a new issue or comment in your copied repository -- follow the instructions, complete the task, and Mona advances you automatically Track progress by watching the Issues tab -- open issues are pending steps, closed issues are completed steps How GitHub Skills Works Each course follows the same pattern: Navigate to the course URL and select "Start course" GitHub copies the course repository to your account Mona (GitHub's automated learning bot) opens an issue with Step 1 instructions within 20 seconds You complete the task described in the issue (create a branch, edit a file, open a PR) Mona detects your action, validates it, and posts the next step as a comment or new issue Repeat until Mona closes the final issue with a completion message All interaction happens through GitHub's standard interface. The screen reader navigation skills from this workshop - heading navigation, landmark jumping, issue and PR workflows - apply directly. For detailed screen reader navigation instructions, see Appendix U Section 3 (GitHub Skills) . Courses Used in This Workshop These three modules are integrated into the Day 1 agenda. You complete them during the workshop with facilitator guidance. The following table lists the three GitHub Skills modules used during Day 1, with their workshop block and what each teaches. Module Workshop Block What Mona Teaches Link Introduction to GitHub Day 1, Blocks 1-3 Branches, commits, pull requests, merge Start course Communicate Using Markdown Day 1, Block 3 Headings, emphasis, links, code blocks, task lists, tables Start course Review Pull Requests Day 1, Block 4 Assign reviewers, leave comments, suggest changes, approve, merge Start course If you did not finish these during the workshop, complete them first before moving to the paths below. Learning Paths The remaining courses are organized into six learning paths. Each path builds on skills from this workshop and progresses from introductory to advanced. You do not need to complete every path - choose the ones that match your goals. Learning Cards: Navigating Learning Paths Screen reader users The six learning paths below are organized as H3 headings with tables listing courses in recommended order -- press 3 to jump between paths, then T to enter each course table Each course link is in the rightmost "Link" column of the table -- navigate to it with arrow keys after entering the table Use the Personal Completion Checklist at the bottom of this appendix as a progress tracker -- copy it into a GitHub issue or personal notes file Low vision users Each learning path table has columns for Order, Module, Duration, Prerequisite, What You Learn, and Link -- widen your browser if columns appear truncated at high zoom Course durations range from 30 minutes to 2 hours -- the Duration column helps you plan which courses fit your" }, + { + "id": "docs/appendix-j-cloud-editors.html", + "title": "Appendix J: GitHub Codespaces", + "url": "docs/appendix-j-cloud-editors.html", + "body": "Appendix J: GitHub Codespaces Listen to Episode 31: GitHub Codespaces - a conversational audio overview of this chapter. Listen before reading to preview the concepts, or after to reinforce what you learned. Reference companion to: Chapter 01: Choose Your Tools | Also relevant: Chapter 11 Authoritative source: GitHub Docs: Codespaces Cloud Development Environments - Accessibility Guide GitHub Codespaces gives you a full VS Code development environment in your browser or connected to your local VS Code, running on a cloud machine. For screen reader users, this means a consistent, pre-configured environment with no local setup required. Table of Contents What Is GitHub Codespaces? Creating a Codespace Codespace Environments Accessibility in Codespaces Screen Reader Configuration Keyboard Shortcuts in Codespaces Managing Your Codespaces Dotfiles and Persistent Configuration Codespaces vs GitHub.dev Common Issues and Workarounds 1. What Is GitHub Codespaces? A Codespace is a cloud-hosted development environment. When you open one, GitHub provisions a virtual machine, clones your repository into it, and connects it to a VS Code interface - either in your browser or via your local VS Code Desktop. Why this matters for accessibility No local installation of tools, compilers, or language runtimes required Your screen reader and OS settings stay on your machine; only the editor runs in the cloud VS Code's full accessibility features (audio cues, screen reader optimized mode, diff viewer) are available The environment is identical for every workshop participant - facilitators can reproduce issues reliably Free tier: GitHub provides a monthly free allowance of Codespace hours for personal accounts. Workshop usage typically falls well within the free tier. Learning Cards: Cloud Editors Overview Screen reader users Codespaces gives you a full VS Code interface with terminal access -- your screen reader and OS settings stay on your local machine The browser-based editor activates screen reader optimized mode automatically if your OS signals a screen reader is running Connect a Codespace to your local VS Code Desktop (via the Codespaces extension) for the most familiar screen reader experience Low vision users Settings Sync carries your font size, theme, and zoom preferences from local VS Code into Codespaces automatically The browser-based editor supports Ctrl+= / Ctrl+- zoom just like desktop VS Code Use a high-contrast VS Code theme -- it applies identically in the cloud editor Sighted users Press . on any GitHub repository page to open it instantly in github.dev (browser editor, no terminal) Codespaces provisions a full VM with terminal -- use it when you need to run code, not just edit The default 2-core machine is sufficient for workshop exercises; upgrade only for heavy builds 2. Creating a Codespace From a Repository Page Navigate to the repository on GitHub Press the Code button (keyboard shortcut: there is no direct shortcut - Tab to the button) In the panel that opens, choose the Codespaces tab Activate Create codespace on main (or your branch name) The Codespace opens in a new browser tab after provisioning (typically 30-60 seconds) From the Codespaces Dashboard Go to github.com/codespaces Activate New codespace Use the search field to find your repository Choose a branch, machine type, and region Activate Create codespace Machine Types Type CPU RAM Best for 2-core 2 vCPU 8 GB General development, documentation 4-core 4 vCPU 16 GB Builds, tests, moderate workloads 8-core 8 vCPU 32 GB Heavy builds, multiple services For workshop exercises, the default 2-core machine is sufficient. 3. Codespace Environments Browser (VS Code for the Web) The Codespace opens directly in your browser as a fully functional VS Code interface. Works in Chrome, Edge, Firefox, and Safari Screen reader support varies slightly by browser - Chrome and Edge have the most consistent behavior with NVDA and JAWS No installation needed Some VS Code extensions are not available in the browser version Local VS Code Desktop If you prefer your local VS Code setup with your extensions and settings: Install the GitHub Codespaces extension in VS Code Sign in to GitHub in VS Code Open the Command Palette ( Ctrl+Shift+P / Cmd+Shift+P ) Run Codespaces: Connect to Codespace Select an existing Codespace or create a new one When connected via local VS Code, your screen reader interacts with your local VS Code installation - all your familiar settings apply. 4. Accessibility in Codespaces Screen Reader Optimized Mode When VS Code detects a screen reader, it automatically activates Screen Reader Optimized mode. You can verify or toggle it manually: Open the Command Palette ( Ctrl+Shift+P ) Search for Toggle Screen Reader Accessibility Mode Press Enter to activate In this mode: The editor reads content line by line instead of character by character Diff views are rendered as accessible text comparisons Inline suggestions from Copilot are announced on a key" + }, { "id": "agents/image alt text agent/agents/image-alt-text.agent.html", "title": "image-alt-text.agent", @@ -2189,6 +2189,12 @@ "url": "admin/planning/DEPLOYMENT_ASSESSMENT.html", "body": "Deployment Assessment: Hybrid Provisioning System Date: June 2, 2026 Status: READY FOR PRODUCTION (with caveat below) Summary The Hybrid provisioning system is architecturally sound, hardened, and production-ready . However, the end-to-end workflow has not yet been tested with real student enrollment . Recommendation: Run Phase 4 smoke test before admitting first cohort. Hardening Assessment by Component OK: GitHub App Configuration Status: HARDENED Why: Fine-grained permissions (least privilege), secrets stored in GitHub Actions only, PEM key never in code Risk: None identified Action: READY OK: Secrets & Variables Management Status: HARDENED Why: All three secrets (App ID, Installation ID, PEM) stored securely in GitHub repository Actions secrets; variables configured correctly Risk: None identified Action: READY OK: Infrastructure Code (Provisioning Scripts) Status: HARDENED Why: Idempotent: Re-running is safe (already-exists vs. created state) Self-healing: Missing students auto-provisioned on next run Deterministic: Uses GitHub API signals, not external state Auditable: All history in provisioning-log.json and git Risk: None identified Action: READY OK: Documentation Updates Status: COMPLETE What: 15+ files updated, 37+ files deleted, HTML regenerated on both sites Coverage: Student-facing, facilitator, operator all covered Risk: None identified Action: READY OK: Public Site Deployments Status: COMPLETE Coverage: community-access.org/git-going-with-github (auto via GitHub Pages) lp.csedesigns.com/ggg (manual via rsync + Caddy reload) Verification: Both sites live and tested (404s work, navigation intact) Risk: None identified Action: READY Warning: End-to-End Student Workflow (NOT YET TESTED) Status: UNTESTED What's missing: Admin roster repo creation Smoke test with test student account Verification that provision workflow runs end-to-end Verification that invitation email sent to test account Verification that student can accept invite and access repo Risk: Medium-logical gaps possible, though architecture is solid Action: REQUIRED-Run Phase 4 before admitting real students What Has Been Tested OK: Automation tests: 78/78 passing (was 98, reduced after removing Classroom tests) OK: Provisioning tests: 55/55 passing OK: HTML regeneration: 393 markdown files -> HTML OK: Site deployments: Both production sites live OK: GitHub App creation: Properly configured with correct permissions OK: Secrets storage: All three values stored securely What Has NOT Been Tested Missing: End-to-end provisioning flow with a real test student Enrollment form submission Issue creation in test account Automation comment with learning room link Provisioning workflow execution Private repo creation and invitation Student repo readiness for challenges Failsafe Mechanisms Mechanism How It Works When It Helps Idempotence Re-running workflow is safe; state tracked in roster.json If automation fails, re-run fixes it Self-healing Missing students auto-provisioned on next run If student missed by error, they're caught on retry Audit Trail provisioning-log.json records every action Troubleshooting, rollback, verification Source of Truth roster.json is canonical; all state derives from it Repo can be recreated, roster is immutable Least Privilege GitHub App has minimal permissions Limits blast radius if credentials compromised Secrets in Actions PEM never stored in code or logs Prevents accidental exposure Deterministic Signals Progress tracked via GitHub events No hidden external dependencies Recommendations Before Go-Live MUST DO (Blocking) Run Phase 4 Smoke Test Create test admin roster repo Add one test learner (e.g., a throwaway GitHub account you control) Trigger provisioning workflow with dry-run first Trigger provisioning workflow without dry-run Verify: Private repo created Invitation sent to test account Roster entry updated to "provisioned" provisioning-log.json records "created" Run again; verify log records "already-exists" Test account accepts invite; repo is ready for challenges Verify End-to-End Student Flow Submit enrollment form as test student Verify issue created in your account Reply ack to issue Verify automation comment posts learning room link Verify you receive GitHub invitation Accept invitation; verify repo has challenges SHOULD DO (Recommended, not blocking) Verify Flask Companion (Optional) If deploying companion for web enrollment, test locally first See Phase 5 of deployment guide Document Rollback Plan If provisioning fails, how to revert? If student repo corrupted, how to re-provision? Document in runbook Test with Multiple Students Once Phase 4 passes, add 3-5 test students to roster Verify all get provisioned correctly Verify no duplicates or conflicts NICE TO HAVE (After launch) Monitor first week of production: Track provisioning success rate Log any failures to support channel Verify no duplicate repos Verify all students receive invitations Set up alert" }, + { + "id": "admin/planning/index.html", + "title": "Planning Archive and Initiative Status", + "url": "admin/planning/index.html", + "body": "Planning Archive and Initiative Status One consolidated index of the project's planning documents. Each initiative below has a status, a summary of what shipped, and a pointer to the full original document (preserved unedited in this folder). New planning documents belong here, not in the repository root. How to read this folder Shipped means the feature is live and the planning document is retained only as a historical record and decision log. In flight means the plan still has open work; the document remains the working checklist. Durable, current documentation always lives in the operational docs (SPEC.md, admin/ guides, .github/README.md), never in this archive. Initiative status Initiative Status Document Hybrid provisioning deployment Shipped (July 2026) DEPLOYMENT_ASSESSMENT.md Provisioning failure review and hardening Shipped (July 2026) REVIEW-2026-07-02.md Podcast site reorganization (content repo to lp.csedesigns.com) In flight REORG-PLAN.md Stage 3 cutover checklist for the reorganization In flight (gated on REORG-PLAN) SHIP-CHECKLIST.md Site information architecture (Stage 1.3) Approved input to REORG-PLAN SITE-IA.md Tooling inventory (Stage 1.4) Complete input to REORG-PLAN TOOLING-INVENTORY.md Shipped initiative summaries Hybrid provisioning (replaces GitHub Classroom) Planned in DEPLOYMENT_ASSESSMENT.md (June 2, 2026), hardened after the July 2 incident review. Live since July 2026: the provision-learning-rooms.yml workflow runs .github/scripts/provisioning/ (pure-orchestration core, injected GitHub client, serial with backoff, idempotent), creates each learner's private room from learning-room-template , invites the learner, and seeds Challenge 1. The algorithm is specified in SPEC.md section 7.2b. Key lesson encoded from the review: no READY claim without a green run ID; the smoke test is the gate. Provisioning failure review (July 2, 2026) Root-caused the provisioning credential failures, added the health-check workflow and alerting, closed the registration-to-roster gap, and tolerated pending collaborator invitations. All action items in its sections 3, 4.1-4.4, and 6 were implemented; see the document for the incident narrative and lessons. Peer simulation seeding (July 4, 2026, no standalone plan document) The Classroom removal deleted Seed-PeerSimulation.ps1 without a replacement, leaving every learning room without the peer-simulation issue and PR that Challenges 1-13 reference (support issue 58). The Student Progression Bot now seeds and self-repairs those artifacts automatically (PR 238), Challenges 10-11 were repointed at the learner's own room (PR 239), and all active rooms were remediated in place. Removed in the July 2026 cleanup datetime (empty stray file at the root) GitHub Learning Room.docx (February draft, superseded by docs/) COMING_SOON.md (pre-launch teaser, workshop is live) github/index.html (redirect stub never served; GitHub Pages deploys only the html/ artifact) Authoritative Sources Use these official references when you need the current source of truth for facts in this file. GitHub Actions documentation - workflow behavior referenced by the shipped initiatives GitHub Pages documentation - deployment model that made the root redirect stub dead weight GitHub REST API documentation - provisioning and seeding API calls Section-Level Source Map Use this map to verify facts for each major section in this file. Initiative status: the linked planning documents in this folder Hybrid provisioning: SPEC.md section 7.2b, DEPLOYMENT_ASSESSMENT.md Provisioning failure review: REVIEW-2026-07-02.md Peer simulation seeding: .github/scripts/challenge-progression.js in learning-room/ , PRs 238 and 239 Removed in cleanup: git history (commit for this change)" + }, { "id": "admin/planning/REORG-PLAN.html", "title": "Git Going with GitHub - Reorganization Master Plan", @@ -2219,12 +2225,6 @@ "url": "admin/planning/TOOLING-INVENTORY.html", "body": "Tooling Inventory (Stage 1.4) Purpose: identify every source file in the content repo and the deploy/site repo that hardcodes an episode identifier, an appendix letter, or an audio slug, so Stage 1.3 (Site IA) and Stage 2+ (refactor) can be scoped accurately. The canonical identity source is now docs/EPISODE_MAP.json . Every locked field below should ultimately resolve through that map by narration_id , filename , or topic_prefix + topic_number . Scope of this inventory: Source-controlled tooling and authoring files in c:\\code\\git-going-with-github . Top-level scripts ( generate-*.bat , build-rss-feed.bat , validate-rss-feed.bat , generate-podcast-scripts.py ). podcasts/ tooling and configuration (excluding audio/ , chapters/ , transcripts/ , bundles/ , challenge-bundles/ , logs/ , _backups/ , _snapshot-*/ , llm-podcast-generator-review/generated/ , __pycache__/ ). scripts/ directory. docs/ (excluding EPISODE_MAP.json and EPISODE-MAP-SCHEMA.json ). admin/ markdown. Site repo c:\\code\\ggg . Out of scope (excluded as noise): html/ (generated site output). podcasts/audio/ (binary tagged mp3s, already updated). podcasts/_snapshot-pre-tagging-20260518/ , podcasts/_snapshot-pre-gpt55-20260518-164221/ , podcasts/_backups/ (snapshots). podcasts/logs/ , tmp-* files. podcasts/chapters/ , podcasts/transcripts/ , podcasts/bundles/ , podcasts/challenge-bundles/ (regenerable build outputs). podcasts/llm-podcast-generator-review/generated/ (regression run outputs). node_modules/ , .git/ , epub/ , learning-room/ (out of reorg scope). Counts shown below are raw hits from ripgrep against the patterns \\bep[0-9]{2}\\b , appendix-[a-z]+ , and cc-bonus-[a-e] . Group A: Live tooling that drives audio identity (MUST refactor) These files are part of the active audio/feed pipeline. Each one currently encodes the legacy ep##-slug / cc-NN-slug / cc-bonus-X-slug identity scheme and will need to switch to the canonical map. File Counts Role Refactor required podcasts/config/listening-order.json 58 ep, 5 bonus Defines the listener-facing order of all 79 items by slug, grouped by section headers ("Day 1: Issues...", "Day 2: ..."). Consumed by podcasts/lib/listening-plan.js , podcasts/generate-site.js , and the RSS feed builder via npm run build:podcast-site . Heavy. Replace with derivation from EPISODE_MAP.json track_number ordering. Section headers will need to be added as a new field on map entries (e.g. section_title ) or driven by learning_band groupings. Decision needed: keep section breaks, or flatten to single-stream feed. podcasts/build-bundles.js 77 appendix-, plus a large hardcoded const episodes = [...] array Generates NotebookLM source bundles for each episode. Carries the entire episode catalog inline ( slug , sources , concepts , crossRefs , prerequisites , duration ) and a SOURCE_ALIASES table that maps historical docs/*.md filenames to current ones. Consumed by npm run build:podcast-bundles and indirectly by generate-transcripts.bat . Heavy. The hardcoded episodes array is the parallel catalog of truth. Refactor to read from EPISODE_MAP.json and a separate bundle-config.json (concepts / crossRefs / prerequisites are bundle-only data not in the map; keep them, but key them by narration_id ). SOURCE_ALIASES is an orthogonal docs/* concern. podcasts/build-challenge-bundles.js 3 appendix- Companion to build-bundles.js for the 16 challenges and 5 bonus challenges. Same shape: inline catalog of slugs. Heavy. Same treatment as build-bundles.js . Key challenge bundles by challenge narration_id / topic_prefix=cc / topic_prefix=cc-bonus . podcasts/generate-draft-transcripts.js 1 ep## ref Generates the draft podcasts/scripts/**/*.txt files. Slug-aware: emits to podcasts/scripts/{chapters,challenges,appendices}/<slug>.txt . The three-bucket directory structure ( chapters/ , challenges/ , appendices/ ) is hardcoded. Medium. The three-bucket layout no longer matches the locked nine-band model (chapter, challenge, bonus, ref, git, tools, agents, sec, a11y). Decision needed: rename appendices/ to nine band-named subdirs, or keep flat. podcasts/tts/generate_episode.py 4 ep## TTS dispatcher invoked by generate-audio*.bat via python -m podcasts.tts.generate_audio --slug <slug> . Resolves slug to a script path under podcasts/scripts/{chapters,challenges,appendices}/<slug>.txt . Medium. Update path resolution if podcasts/scripts/ layout changes. Otherwise the script name (still ep##-... ) is the lookup key for the existing 79 mp3s, so this can stay slug-keyed until filenames are rotated in Stage 2. podcasts/tts/generate_all_kokoro.py 2 ep## Higher-level batch driver around generate_episode.py . Low. Same pattern as generate_episode.py . podcasts/listening_plan.py 1 ep## Reads podcasts/config/listening-order.json and emits a structured plan. Medium. Refactor once listening-order.json is replaced with map-derived ordering. podcasts/generate-site.js 1 ep## Builds podcasts/feed.xml and admin/PODCASTS.md . Consu" }, - { - "id": "admin/planning/index.html", - "title": "Planning Archive and Initiative Status", - "url": "admin/planning/index.html", - "body": "Planning Archive and Initiative Status One consolidated index of the project's planning documents. Each initiative below has a status, a summary of what shipped, and a pointer to the full original document (preserved unedited in this folder). New planning documents belong here, not in the repository root. How to read this folder Shipped means the feature is live and the planning document is retained only as a historical record and decision log. In flight means the plan still has open work; the document remains the working checklist. Durable, current documentation always lives in the operational docs (SPEC.md, admin/ guides, .github/README.md), never in this archive. Initiative status Initiative Status Document Hybrid provisioning deployment Shipped (July 2026) DEPLOYMENT_ASSESSMENT.md Provisioning failure review and hardening Shipped (July 2026) REVIEW-2026-07-02.md Podcast site reorganization (content repo to lp.csedesigns.com) In flight REORG-PLAN.md Stage 3 cutover checklist for the reorganization In flight (gated on REORG-PLAN) SHIP-CHECKLIST.md Site information architecture (Stage 1.3) Approved input to REORG-PLAN SITE-IA.md Tooling inventory (Stage 1.4) Complete input to REORG-PLAN TOOLING-INVENTORY.md Shipped initiative summaries Hybrid provisioning (replaces GitHub Classroom) Planned in DEPLOYMENT_ASSESSMENT.md (June 2, 2026), hardened after the July 2 incident review. Live since July 2026: the provision-learning-rooms.yml workflow runs .github/scripts/provisioning/ (pure-orchestration core, injected GitHub client, serial with backoff, idempotent), creates each learner's private room from learning-room-template , invites the learner, and seeds Challenge 1. The algorithm is specified in SPEC.md section 7.2b. Key lesson encoded from the review: no READY claim without a green run ID; the smoke test is the gate. Provisioning failure review (July 2, 2026) Root-caused the provisioning credential failures, added the health-check workflow and alerting, closed the registration-to-roster gap, and tolerated pending collaborator invitations. All action items in its sections 3, 4.1-4.4, and 6 were implemented; see the document for the incident narrative and lessons. Peer simulation seeding (July 4, 2026, no standalone plan document) The Classroom removal deleted Seed-PeerSimulation.ps1 without a replacement, leaving every learning room without the peer-simulation issue and PR that Challenges 1-13 reference (support issue 58). The Student Progression Bot now seeds and self-repairs those artifacts automatically (PR 238), Challenges 10-11 were repointed at the learner's own room (PR 239), and all active rooms were remediated in place. Removed in the July 2026 cleanup datetime (empty stray file at the root) GitHub Learning Room.docx (February draft, superseded by docs/) COMING_SOON.md (pre-launch teaser, workshop is live) github/index.html (redirect stub never served; GitHub Pages deploys only the html/ artifact) Authoritative Sources Use these official references when you need the current source of truth for facts in this file. GitHub Actions documentation - workflow behavior referenced by the shipped initiatives GitHub Pages documentation - deployment model that made the root redirect stub dead weight GitHub REST API documentation - provisioning and seeding API calls Section-Level Source Map Use this map to verify facts for each major section in this file. Initiative status: the linked planning documents in this folder Hybrid provisioning: SPEC.md section 7.2b, DEPLOYMENT_ASSESSMENT.md Provisioning failure review: REVIEW-2026-07-02.md Peer simulation seeding: .github/scripts/challenge-progression.js in learning-room/ , PRs 238 and 239 Removed in cleanup: git history (commit for this change)" - }, { "id": "classroom/assignment-issue-template.html", "title": "Assignment Issue Template Reference", diff --git a/html/work.html b/html/work.html index b5940212..2f61f0c6 100644 --- a/html/work.html +++ b/html/work.html @@ -570,6 +570,10 @@

    If you get stuck

    Look for a pencil icon near the top-right of the file view. Screen reader users: the button is labeled "Edit this file". +I am using github.dev and Commit and Push is disabled, or Ctrl+Enter does nothing +You still have write access - the editor's copy of the repository is out of date (your Learning Room receives workshop updates from time to time). Reload the browser tab, or press the period key on the repository page to reopen github.dev. Your unsaved edits are kept in browser storage and come back after the reload. Then check the Accounts button confirms you are signed in, and commit again. If it stays disabled, use the "Edit this file" pencil editor on GitHub.com instead - it always works. + + I accidentally committed to main Ask your facilitator for help. This is fixable. diff --git a/learning-room/.github/ISSUE_TEMPLATE/challenge-05-make-your-mark.yml b/learning-room/.github/ISSUE_TEMPLATE/challenge-05-make-your-mark.yml index 36b35691..4228854e 100644 --- a/learning-room/.github/ISSUE_TEMPLATE/challenge-05-make-your-mark.yml +++ b/learning-room/.github/ISSUE_TEMPLATE/challenge-05-make-your-mark.yml @@ -56,5 +56,6 @@ body: |---|---| | I am editing on main instead of my branch | Switch to your branch first using the branch dropdown, then edit the file. | | I cannot find the edit button | Look for a pencil icon near the top-right of the file view. Screen reader users: the button is labeled "Edit this file". | + | I am using github.dev and Commit and Push is disabled, or Ctrl+Enter does nothing | You still have write access - the editor's copy of the repository is out of date (your Learning Room receives workshop updates from time to time). Reload the browser tab, or press the period key on the repository page to reopen github.dev. Your unsaved edits are kept in browser storage and come back after the reload. Then check the Accounts button confirms you are signed in, and commit again. If it stays disabled, use the "Edit this file" pencil editor on GitHub.com instead - it always works. | | I accidentally committed to main | Ask your facilitator for help. This is fixable. | | I finished but want to check my work | [View the reference solution](https://github.com/Community-Access/git-going-with-github/blob/main/docs/solutions/solution-05-make-your-mark.md) | diff --git a/work.md b/work.md index 2100e16d..5ea318be 100644 --- a/work.md +++ b/work.md @@ -298,6 +298,7 @@ Compare your commit message with the peer-simulation PR title and commit message |---|---| | I am editing on main instead of my branch | Switch to your branch first using the branch dropdown, then edit the file. | | I cannot find the edit button | Look for a pencil icon near the top-right of the file view. Screen reader users: the button is labeled "Edit this file". | +| I am using github.dev and Commit and Push is disabled, or Ctrl+Enter does nothing | You still have write access - the editor's copy of the repository is out of date (your Learning Room receives workshop updates from time to time). Reload the browser tab, or press the period key on the repository page to reopen github.dev. Your unsaved edits are kept in browser storage and come back after the reload. Then check the Accounts button confirms you are signed in, and commit again. If it stays disabled, use the "Edit this file" pencil editor on GitHub.com instead - it always works. | | I accidentally committed to main | Ask your facilitator for help. This is fixable. | | I finished but want to check my work | [View the reference solution](https://github.com/Community-Access/git-going-with-github/blob/main/docs/solutions/solution-05-make-your-mark.md) |