How princephantom-cm/portswigger-lab-tracker works
1. Repository purpose
- This is a personal progress tracker and knowledge base for PortSwigger Web Academy labs, not a traditional application with backend services.
- The architecture is content-first: one public tracker page plus topic writeups documenting lessons learned.
2. Primary presentation surface
- index.html is the core user-facing artifact.
- It is likely the static tracker page used by the GitHub Pages live site, showing overall lab progress and topic prioritization.
3. Documentation surface
- README.md acts as the repository landing page and high-level status summary.
- It communicates current completion count, topic priorities, and links to writeups and external profiles.
4. Knowledge base subsystem
- The writeups/ directory holds topic-specific notes.
- writeups/access-control.md is the first concrete example and represents a pattern the repo is expected to grow with: one markdown document per topic.
5. Content flow
- The author studies PortSwigger labs externally, then updates the tracker and adds writeups in this repo.
- The resulting flow is: lab completion and learning → markdown notes / tracker updates → static publication.
6. Hosting and delivery
- The live tracker is published on GitHub Pages.
- That means the repository is served as a static site: no database, no API, no server-side rendering layer visible in this repo.
7. External dependencies
- The main external source of truth is PortSwigger Web Academy, which provides the labs being tracked.
- LinkedIn is used as a social distribution channel for weekly progress updates, but it is not part of the application architecture.
8. Data model
- The main “data” in the repo is editorial rather than transactional: completion counts, topic ordering, and written summaries.
- There is no evidence of user accounts, authentication, or dynamically generated state inside the repo.
9. Functional boundaries
- Tracker boundary: progress visualization and lab prioritization.
- Writeup boundary: explanatory notes and real-world relevance mapping.
- Metadata boundary: README content and outbound links for navigation and context.
10. Operational characteristics
- This repo is lightweight and static, with no build system or runtime services shown in the provided tree.
- Changes are likely manual edits to HTML/Markdown followed by redeployment through GitHub Pages.
11. What an architecture diagram should show
- A single static content repository feeding a GitHub Pages site.
- Separate content lanes for index.html tracker content and writeups/*.md learning notes.
- External inputs from PortSwigger labs and outbound sharing to LinkedIn.
12. Overall shape
- The architecture is best described as a static documentation site with a progress dashboard, maintained by one author and published directly from GitHub.
Main entry points: index.html Tracker page · writeups Writeups · README.md README.md · access-control.md Access control
Components 8
Repository
Static content maintained in the repo and published as a GitHub Pages site.
- README.md · Repository overview, current progress, priorities, and outbound context.
README.md - Tracker page · Primary public progress view showing lab completion and topic prioritization.
index.html - Writeups · Topic-by-topic markdown notes capturing lessons learned from labs.
writeups - Access control · First concrete writeup example for one lab area and a template for future notes.
writeups/access-control.md - Manual updates · Human-driven editing of HTML and Markdown after studying labs externally.
External
Outside services and sources that feed or receive the content.
- GitHub Pages · Publishes the repository as a static site with no server-side runtime.
- PortSwigger Labs · External source of truth for labs, challenges, and study material.
- LinkedIn · Outward-facing channel for progress updates and weekly summaries.
Connections 10
- PortSwigger Labs → Manual updates: study material · Labs are studied externally before content is updated.
- Manual updates → Tracker page: update · Manual edits refresh the progress dashboard and topic priorities.
- Manual updates → Writeups: add notes · Manual edits add or expand topic writeups in Markdown.
- Writeups → Access control: contains · The writeups directory contains topic-specific documents such as access control.
- README.md → Tracker page: summarizes · README provides the public landing summary for the tracker site.
- README.md → Writeups: links · README points readers toward the writeup collection.
- Tracker page → GitHub Pages: published via · The tracker page is served as static content on GitHub Pages.
- Writeups → GitHub Pages: published via · Writeups are also delivered as static repository content.
- README.md → GitHub Pages: published via · The repository landing page is part of the static site surface.
- Tracker page → LinkedIn: shared as updates · Progress snapshots are distributed externally through LinkedIn posts.