landerox.github.io

When a user attempts to read or modify a sensitive resource in the project's authoritative repository, the system MUST require the user to complete a multi-factor authentication process. [OSPS-AC-01.01] Multi-factor authentication required when accessing sensitive resources in the repository. The repository owner has GitHub 2FA enabled. Repository-sensitive operations (settings, secrets, deploy keys, rulesets, branch protection) require an authenticated session with the second factor. The project currently has no collaborators with sensitive-resource access beyond the owner.

When a new collaborator is added, the version control system MUST require manual permission assignment, or restrict the collaborator permissions to the lowest available privileges by default. [OSPS-AC-02.01] New collaborators receive minimum permissions by default. The repository has no collaborators beyond the owner, GitHub's default behaviour assigns the lowest applicable role to a newly added collaborator, and should a collaborator ever be added the repository ruleset "Main Branch Protection" (id 11709250) constrains writes to the default branch independently of the per-collaborator role.

When a direct commit is attempted on the project's primary branch, an enforcement mechanism MUST prevent the change from being applied. [OSPS-AC-03.01] Direct commits to the primary branch are prevented. The repository ruleset "Main Branch Protection" (id 11709250, URL https://github.com/landerox/landerox.github.io/rules/11709250) enforces a pull_request rule on the default branch main with required_approving_review_count = 1, required_status_checks (lint, build) that must pass before merge, non_fast_forward to prevent force pushes, and required_linear_history; the repository owner has admin bypass per the ruleset bypass_actors configuration as a deliberate single-maintainer flow documented in AGENTS.md hard rules.

When an attempt is made to delete the project's primary branch, the version control system MUST treat this as a sensitive activity and require explicit confirmation of intent. [OSPS-AC-03.02] Primary branch deletion requires explicit confirmation. The repository ruleset "Main Branch Protection" includes the deletion rule type, which blocks deletion of the default branch main entirely; GitHub enforces this for all users, including admins (the bypass_actors setting applies only to push operations, not deletion).

When a CI/CD pipeline operates on untrusted metadata, those parameters MUST be sanitized and validated prior to use in the pipeline. [OSPS-BR-01.01] CI/CD pipeline parameters from untrusted sources must be sanitised. CI workflows accept no parameters from untrusted sources: workflow_dispatch inputs are limited (none defined), pull requests from forks run with the default GitHub fork-PR permission model (read-only token, no secret exposure), and workflow security is continuously audited by zizmor in pre-commit with a strict hash-pin policy and by lint.yml CI on every push plus a daily 08:00 UTC cron.

(Future criterion) When a CI/CD pipeline operates on untrusted code snapshots, it MUST prevent access to privileged CI/CD credentials and assets. [OSPS-BR-01.03] CI/CD prevents untrusted code from accessing privileged credentials. Workflow tokens follow least privilege: top-level permissions: contents: read is declared in lint.yml, deploy.yml, links.yml, quality.yml and uv-upgrade.yml; elevated permissions (pages: write, id-token: write, contents: write, pull-requests: write, security-events: write) are declared per-job rather than workflow-level; the only workflow with contents: write (uv-upgrade.yml) runs only on schedule and workflow_dispatch (maintainer-triggered), never on external PRs; fork PRs receive a read-only GITHUB_TOKEN per GitHub default policy; and zizmor continuously audits these patterns so any regression fails CI.

When the project lists a URI as an official project channel, that URI MUST be exclusively delivered using encrypted channels. [OSPS-BR-03.01] Official project channels use encrypted transmission only. All project channels are HTTPS-only: the repository at https://github.com/landerox/landerox.github.io (HTTPS-only), the published site at https://landerox.com (GitHub Pages with HTTPS enforced), devcontainer image pulls from mcr.microsoft.com and ghcr.io over HTTPS, Python package retrieval from PyPI over HTTPS via uv, and tag downloads from GitHub Releases over HTTPS; no HTTP, FTP, or other unencrypted channels are used.

When the project lists a URI as an official distribution channel, that channel MUST be protected from adversary-in-the-middle attacks using cryptographically authenticated channels. [OSPS-BR-03.02] Distribution channels protected against man-in-the-middle attacks. Multiple layers of MITM protection are in place: GitHub Action references are SHA-pinned (sha40 + version comment) via pinact and continuously verified by zizmor's hash-pin policy; uv.lock pins each Python dependency by SHA256 hash and uv sync --frozen verifies hashes on every install; container images in.devcontainer/Dockerfile are pinned by SHA256 digest (tag@sha256:…) for both mcr.microsoft.com/devcontainers/python and ghcr.io/astral-sh/uv; and all registry endpoints use TLS with certificate verification by default.

The project MUST prevent the unintentional storage of unencrypted sensitive data, such as secrets and credentials, in the version control system. [OSPS-BR-07.01] Sensitive data prevented from storage in version control. detect-secrets runs in the pre-commit suite with a curated baseline at.config/.secrets.baseline; the pre-commit suite is blocking (bypass via --no-verify is forbidden by AGENTS.md hard rules); the repository contains no API keys, deploy keys, service tokens, or cloud credentials; CI workflows use ephemeral ${{ secrets.GITHUB_TOKEN }} provided by GitHub on each run.

When the project has made a release, the project documentation MUST include user guides for all basic functionality. [OSPS-DO-01.01] https://github.com/landerox/landerox.github.io/blob/main/README.md README.md documents installation (devcontainer or host with uv + just), startup (just serve / just serve-es), usage (just build), and security (SECURITY.md cross-link). Deeper internal docs live under docs/ (tooling, decisions, structure, style-guide, runbook). [documentation_basics]

When the project has made a release, the project documentation MUST include a guide for reporting defects. [OSPS-DO-02.01] https://github.com/landerox/landerox.github.io/issues/new/choose Bug reports are submitted through GitHub Issues using the templates under.github/ISSUE_TEMPLATE/ (bug_report.yml and feature_request.yml). The "/issues/new/choose" page lets reporters pick the appropriate template. [report_process]

While active, the project MUST have one or more mechanisms for public discussions about proposed changes and usage obstacles. [OSPS-GV-02.01] GitHub supports public discussions on proposed changes (via pull requests) and usage obstacles (via issues).

While active, the project documentation MUST include an explanation of the contribution process. [OSPS-GV-03.01] https://github.com/landerox/landerox.github.io/blob/main/.github/CONTRIBUTING.md.github/CONTRIBUTING.md explains the contribution workflow: fork, branch, Conventional Commits (validated by commitizen), pre-commit hooks, and pull-request submission. [contribution]

While active, the license for the source code MUST meet the OSI Open Source Definition or the FSF Free Software Definition. [OSPS-LE-02.01] The MIT license for the repository contents is approved by the Open Source Initiative (OSI).

While active, the license for the released software assets MUST meet the OSI Open Source Definition or the FSF Free Software Definition. [OSPS-LE-02.02] The repository uses a dual-license model: source code (configs, workflows, scripts) is licensed under the MIT License via LICENSE at repo root; site content (Markdown under content/, prose, images) is licensed under Creative Commons Attribution 4.0 International via LICENSE-CONTENT. Both are FLOSS licenses for their respective scopes. Boundary documented in docs/decisions.md (Licensing Boundary). [floss_license]

While active, the license for the source code MUST be maintained in the corresponding repository's LICENSE file, COPYING file, or LICENSE/ directory. [OSPS-LE-03.01] License file found in repository.

While active, the license for the released software assets MUST be included in the released source code, or in a LICENSE file, COPYING file, or LICENSE/ directory alongside the corresponding release assets. [OSPS-LE-03.02] https://github.com/landerox/landerox.github.io/blob/main/LICENSE LICENSE (MIT, source code) is at the repository root in the standard GitHub-recognized location. LICENSE-CONTENT (CC-BY-4.0, site content) is also at the repository root for visibility. [license_location]

While active, the project's source code repository MUST be publicly readable at a static URL. [OSPS-QA-01.01] Public repository accessible at a static URL. https://github.com/landerox/landerox.github.io is owned by an active GitHub account, has public visibility, requires no authentication to clone or browse, and the URL has been stable since project inception.

The version control system MUST contain a publicly readable record of all changes made, who made the changes, and when the changes were made. [OSPS-QA-01.02] VCS maintains public change history with authorship. Every commit records author name, email, timestamp and a unique SHA, visible at https://github.com/landerox/landerox.github.io/commits/main; Conventional Commits format (validated by commitizen in the commit-msg hook) adds semantic context; CHANGELOG.md provides hand-curated release notes per Keep a Changelog 1.1.0.

When the package management system supports it, the source code repository MUST contain a dependency list that accounts for the direct language dependencies. [OSPS-QA-02.01] Dependency list for direct language dependencies. Direct dependencies are declared explicitly: Python runtime in pyproject.toml under [project] dependencies and [dependency-groups] dev with resolved transitive deps and SHA256 hashes in uv.lock; GitHub Actions in.github/workflows/*.yml where each uses: line references the action by SHA40 + version comment via pinact; devcontainer tools in.devcontainer/Dockerfile as ARGs (UV_VERSION, LYCHEE_VERSION, PINACT_VERSION) with base images pinned by tag + SHA256 digest.

Projects with multiple repositories MUST document a list of codebases that are part of the project. [OSPS-QA-04.01] Multi-repository projects document all codebases. N/A — this is a single-repository project, there are no sister or sub repositories, and all project code, configuration, content and documentation live in this single repository.

While active, the version control system MUST NOT contain generated executable artifacts. [OSPS-QA-05.01] Generated executables excluded from version control. The repository contains no compiled executables, no.so/.dll/.exe, no Python.pyc/.pyo, no build artefacts;.gitignore excludes build output (site/), Python caches (.venv/, pycache/, *.py[cod],.pre-commit-cache/), tooling caches (.cache/,.mypy_cache/,.pytest_cache/,.ruff_cache/), IDE/editor files (.idea/,.vscode/, *.swp), OS artefacts (.DS_Store, Thumbs.db), and the devcontainer per-host lockfile (.devcontainer/devcontainer-lock.json).

While active, the version control system MUST NOT contain unreviewable binary artifacts. [OSPS-QA-05.02] Unreviewable binary artifacts excluded. The repository contains no unreviewable binary artefacts; the only binary files present are essential static site assets — all human-inspectable and necessary for site rendering: 4 WOFF2 font files (MesloLGM Nerd Font Propo, Regular and Bold for EN and ES, subsetted from upstream TTF under the SIL OFL license with documented bump procedure in docs/tooling.md), favicon.svg (vector, inspectable), logo.svg (vector), and one profile.webp per locale (human portrait photograph).

While active, the project documentation MUST contain security contacts. [OSPS-VM-02.01] https://github.com/landerox/landerox.github.io/blob/main/.github/SECURITY.md.github/SECURITY.md documents the vulnerability reporting workflow: use GitHub Private Vulnerability Reporting (Security tab > Advisories > Report a vulnerability). It also defines a disclosure policy: 48-hour acknowledgement, 7-day fix-ETA estimate, notification on resolution. [vulnerability_report_process]