Use a repo-level lock manifest plus a GitHub Action (and optional CODEOWNERS) to enforce "locked" files. Paste the Lovable prompt below into your Lovable chat to create the lock manifest, add a GitHub workflow that fails PRs touching locked files, add a CODEOWNERS stub, and insert a top-of-file LOCK banner into any currently-locked files.

What this will add

• locks/locked-files.json — list of locked file patterns (exact path or prefix ending with /\*\*).
• .github/workflows/locked-files-check.yml — GitHub Action that fails PRs when locked files are changed.
• .github/CODEOWNERS — optional reviewers for locked paths (replace placeholders in the file on GitHub).
• Automatic banner insertion — inject a top-of-file comment into files that match the locked patterns so Lovable editors see the lock.

// Prompt to paste into Lovable chat (ask Lovable to implement these repository changes)

Make these repo changes to implement file-locking:

1) Create file locks/locked-files.json with this JSON array (edit patterns later):
[
  "src/core/**",
  "package.json"
]

2) Create file .github/CODEOWNERS with this content (replace @your-org/your-team on GitHub):
# CODEOWNERS for locked files
/src/core/ @your-org/your-team
/package.json @your-org/your-team

3) Create file .github/workflows/locked-files-check.yml with the following workflow:
name: "Block PRs that modify locked files"
on:
  pull_request:
    types: [opened, edited, synchronize, reopened]
jobs:
  check-locked:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check locked files in PR
        uses: actions/github-script@v6
        with:
          script: |
            // Read locked patterns from repo file
            const fs = require('fs');
            const lockedPath = 'locks/locked-files.json';
            if (!fs.existsSync(lockedPath)) {
              throw new Error(`Missing ${lockedPath} — create it to define locked files`);
            }
            const locked = JSON.parse(fs.readFileSync(lockedPath, 'utf8'));
            // Ensure we run in PR context
            const pr = context.payload.pull_request;
            if (!pr) {
              throw new Error('This workflow expects a pull_request event');
            }
            // List changed files in the PR
            const files = await github.paginate(github.rest.pulls.listFiles, {
              owner: context.repo.owner,
              repo: context.repo.repo,
              pull_number: pr.number
            });
            const changed = files.map(f => f.filename);
            // Match patterns: exact paths or prefix/** style
            const matches = [];
            for (const pattern of locked) {
              if (pattern.endsWith('/**')) {
                const prefix = pattern.slice(0, -3);
                for (const f of changed) if (f.startsWith(prefix)) matches.push(f);
              } else {
                for (const f of changed) if (f === pattern) matches.push(f);
              }
            }
            if (matches.length) {
              throw new Error('PR modifies locked files: ' + Array.from(new Set(matches)).join(', '));
            }

4) Insert a top-of-file lock banner into every existing file that matches the patterns in locks/locked-files.json.
   - For JS/TS files insert at file top:
// LOCKED: This file is managed centrally. Do not edit in Lovable. See locks/locked-files.json
   - For other file types, insert a language-appropriate single-line comment at the top with the same message.
   - Update only files that currently match the patterns in locks/locked-files.json.

5) Update README.md with a short note:
"Locked files are listed in locks/locked-files.json. Pull requests that modify locked files will fail CI. To change locks, update locks/locked-files.json and coordinate with the owning team."

Important operational notes (include in the commit message or README):
// Enforcement requires pushing this repository to GitHub and enabling GitHub Actions.
// To require CODEOWNERS approvals as blocking, enable branch protection rules in GitHub (Require review from CODEOWNERS).

Please make all changes in a single commit, and open a PR/Publish so I can Preview the edits here in Lovable.

Next steps after Lovable makes the edits

• Sync/publish to GitHub so the workflow runs. Without GitHub the lock file and banners are documentation only.
• Enable branch protection and require CODEOWNERS approval if you want review-based enforcement (done on GitHub settings).

The simplest, most reliable approach is to combine repository-level controls (CODEOWNERS + GitHub branch protection), an automated GitHub Actions check that fails PRs which modify “protected” paths, and Lovable-side habits: add explicit “DO NOT EDIT” headers to guarded files, use Preview/diffs before Publish, and require human review via CODEOWNERS. Implement these via Lovable by adding the CODEOWNERS file, a CI workflow to reject protected edits, a PROTECTED_FILES manifest, and file headers — then sync to GitHub and enable branch protection in GitHub settings.

Why this works (short)

• CODEOWNERS forces required reviewers on PRs touching guarded files.
• GitHub Actions CI enforces the rule automatically (will fail the PR if protected files changed unexpectedly).
• File headers + PROTECTED\_FILES make intent visible in Lovable’s editor and Preview so teammates don’t accidentally edit.
• Lovable workflow: use Preview + file diffs + Chat Mode edits, and only Publish after the required CODEOWNERS approvals.

Paste these prompts into Lovable’s chat to implement the changes

Prompt — Create CODEOWNERS (creates .github/CODEOWNERS)

Please create a file at .github/CODEOWNERS with entries that require review from the correct team or users for protected paths. Use these exact lines, and replace @org/team or @username with our real GitHub handles:

// Require review from core team for src/core and config files
/src/core/ @org/core-team
/src/config/ @org/core-team
/.github/workflows/ @org/devops

// Require review from frontend team for UI-critical files
/src/ui/ @org/frontend-team

// Add a catch-all if desired
#* @org/review-team

Prompt — Add CI guard that fails PRs changing protected paths (create .github/workflows/protect-protected-files.yml)

Please create a GitHub Actions workflow at .github/workflows/protect-protected-files.yml that runs on pull_request and fails the job if any changed file matches a protected prefix listed in a repo file PROTECTED_FILES. Use this implementation:

// Workflow metadata and trigger
name: Protect guarded files
on: pull_request

jobs:
  check-protected:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          fetch-depth: 0
      - name: Load protected globs
        run: |
          // Create an array of protected prefixes from the PROTECTED_FILES file
          PROTECTED=$(tr '\n' ' ' < PROTECTED_FILES || echo "")
          echo "Protected prefixes: $PROTECTED"
      - name: Get changed files
        env:
          BASE_REF: ${{ github.event.pull_request.base.ref }}
          HEAD_SHA: ${{ github.sha }}
        run: |
          // Fetch the base branch and list changed files between base and PR head
          git fetch origin "$BASE_REF"
          CHANGED=$(git diff --name-only origin/"$BASE_REF"...$HEAD_SHA)
          echo "Changed files: $CHANGED"
          echo "$CHANGED" > changed.txt
      - name: Fail if protected files changed
        run: |
          // For each protected prefix, check if any changed file starts with it; fail if so
          for prefix in $PROTECTED; do
            if [ -z "$prefix" ]; then
              continue
            fi
            if echo "$CHANGED" | grep -E "^$prefix" >/dev/null; then
              echo "Error: changes touch protected path: $prefix"
              echo "Affected files:"
              echo "$CHANGED" | grep -E "^$prefix"
              exit 1
            fi
          done

Prompt — Add PROTECTED_FILES manifest and file headers (create PROTECTED_FILES and add headers)

Please create a file PROTECTED_FILES at the repository root listing path prefixes (one per line) that we consider protected, matching the CODEOWNERS entries. Example content:

// Protected prefixes (one per line)
.github/workflows/
src/core/
src/config/
scripts/deploy/

Also, add a standard header comment to every file under src/core/ and src/config/ that says:
// DO NOT EDIT — maintained by the core team. To request changes, open a PR and tag @org/core-team.
Please add that header to these files: update src/core/index.ts, src/config/index.ts, and any other file under src/core/ to include the first three lines at the top of the file.

Prompt — Lovable workflow guidance to enforce review before Publish

Please add a short CONTRIBUTING.md in the repo root describing the Lovable workflow and expectations, including:
- Always use Lovable Preview to inspect file diffs before Publish.
- Never directly edit files listed in PROTECTED_FILES in Chat Mode; open a normal PR targeting the protected area and request @org/core-team review.
- If a change to a protected file is required, add a PR label "allow-protected-changes" and request explicit CODEOWNER approval.

Create CONTRIBUTING.md with those items under a "How to edit protected code" section.

Final steps (outside Lovable)

• Enable branch protection for main/default in GitHub settings: require status checks (the workflow above) and require CODEOWNERS reviews. This must be done in the GitHub web UI by a repo admin — it cannot be done inside Lovable.
• Sync/Publish from Lovable to GitHub, then open a test PR to verify the workflow blocks protected-file edits and that CODEOWNERS requests reviewers as expected.