Baustellenfotos in Azure Blob Storage sauber benennen

In einem Bauunternehmen wird ein Foto mit dem Namen IMG_4821.jpg spaetestens bei der Uebergabe zum Problem. Die Projektnummer steht auf der Bautafel, die Phase im Chat und der Kunde fragt nach genau den Abdichtungsfotos. Wenn Azure Blob Storage keine klare Benennung und keine Tags bekommt, sucht das Buero in alten Nachrichten. Der erste Schritt ist eine Pruefung von hundert aktuellen Fotos.

Key Points

Verlasse dich nicht auf Kameranamen.
Trenne Projekt, Phase, Ort, Status, Datum und laufende Nummer.
Nutze Blob index tags fuer Suche und metadata fuer Importnotizen.
Claude Code erstellt Regel, CSV und Risikoliste.
Menschen entscheiden ueber Namen, Adressen, Gesichter, Kennzeichen, Verträge und Freigabe.

Workflow: Photo Ledger Before Upload

Beginne mit der echten Fotoliste. Ordner, aktueller Name, Datum, Phase, Ort, Empfaenger und Freigabestatus kommen in eine Tabelle. Claude Code erstellt daraus eine Blob-Pfadregel, Pflicht-Tags und eine Review-CSV.

Field	Example	Review point
Blob name	`2026/07/site-042/waterproof/20260719_roof_before_001.jpg`	readable path without customer details
Blob index tags	`projectId`, `phase`, `location`, `status`, `publicOk`	searchable keys with stable spelling
Metadata	`source=line`, `shotBy=staff-01`	import support, not sensitive identity
Ledger CSV	URL, phase, destination, approval	human review before submission

Primary sources checked: Azure Blob Storage introduction, naming rules, Blob index tags, lifecycle management, soft delete, and SAS overview.

What Claude Code Does And What Humans Decide

Claude Code can draft naming rules, required tags, missing-field checks, CSV columns, shared-link checks, and retention notes from a sample folder. Humans decide customer names, addresses, faces, license plates, neighboring homes, accident photos, contracts, publication approval, and deletion requests.

3 Use Cases

Use case 1: Create a naming rule for site photos

Input: existing folders, photo names, project ID, phase, location, shot date, destination.
Output: blob-name template, sequence rule, banned labels, CSV columns.
Human review: customer names, addresses, and site labels that should not appear in URLs.

Start with one recent site and one hundred photos. Ask Claude Code to turn the list into a naming rule. The human reviewer removes sensitive labels before upload.

Use case 2: Search with Blob index tags

Input: projectId, phase, location, status, shotDate, submittedTo, publicOk.
Output: required tags, search examples, empty-field rule, spelling dictionary.
Human review: no personal data, customer names, addresses, phone numbers, or license plates in tags.

Tags make later search practical. A query by project and phase is easier than scanning camera filenames. Keep tag values short and internal.

Use case 3: Review shared URLs

Input: photos to share, recipient, expiry, permission, email text, submission deadline.
Output: SAS checklist, expiry warning, share list, send-before review.
Human review: recipient, read-only permission, expiry, people in photos, contract details.

Shared URLs reduce back-and-forth, but wide links create risk. Claude Code prepares the table. Humans approve the scope.

Copy-Paste Prompt

Act as a construction photo ledger reviewer.
Goal: make Azure Blob Storage photos searchable without exposing customer or site-sensitive data.

Check:
1. blob names include project, date, phase, location, status, and sequence
2. customer names, addresses, people, and license plates are not placed in URLs or tags
3. Blob index tags and metadata have separate purposes
4. shared URLs are read-only, short-lived, and narrow in scope
5. soft delete, versioning, and lifecycle notes exist
6. a ledger CSV lets humans approve publication

Return a naming rule, required tag table, CSV columns, risky file-name examples, and a 100-photo first review plan.

Working Check Code

// verify-construction-photo-ledger.mjs
// No dependencies. Run with: node verify-construction-photo-ledger.mjs
const photos = [
  {
    blobName: "IMG_4821.jpg",
    tags: { projectId: "site-042", phase: "waterproof" },
    metadata: { source: "line" },
    share: { permission: "read", expiresInHours: 240 }
  },
  {
    blobName: "2026/07/site-042/waterproof/20260719_roof_before_001.jpg",
    tags: {
      projectId: "site-042",
      phase: "waterproof",
      location: "roof",
      status: "before",
      publicOk: "review"
    },
    metadata: { source: "camera", shotBy: "staff-01" },
    share: { permission: "read", expiresInHours: 24 }
  },
  {
    blobName: "sato-home-address-kyoto-crack-after.jpg",
    tags: { projectId: "sato-home", phase: "repair", publicOk: "yes" },
    metadata: { customerName: "Sato" },
    share: { permission: "write", expiresInHours: 72 }
  }
];

const requiredTags = ["projectId", "phase", "location", "status", "publicOk"];
const blobNamePattern = /^\d{4}\/\d{2}\/[a-z0-9-]+\/[a-z0-9-]+\/\d{8}_[a-z0-9-]+_(before|after|progress)_\d{3}\.(jpg|jpeg|png)$/i;
const sensitiveWords = /(address|customer|home|name|phone|car|license|住所|氏名|電話|車番)/i;
const problems = [];

for (const photo of photos) {
  if (!blobNamePattern.test(photo.blobName)) {
    problems.push({ blobName: photo.blobName, item: "blob name", fix: "use yyyy/mm/project/phase/date_location_status_seq.ext" });
  }
  for (const tag of requiredTags) {
    if (!photo.tags[tag]) {
      problems.push({ blobName: photo.blobName, item: `missing tag: ${tag}`, fix: "fill required Blob index tags before upload" });
    }
  }
  if (sensitiveWords.test(photo.blobName) || sensitiveWords.test(JSON.stringify(photo.tags)) || sensitiveWords.test(JSON.stringify(photo.metadata))) {
    problems.push({ blobName: photo.blobName, item: "sensitive label", fix: "remove customer names, addresses, phone numbers, and car identifiers" });
  }
  if (photo.share.permission !== "read") {
    problems.push({ blobName: photo.blobName, item: "share permission", fix: "use read-only sharing for external photo review" });
  }
  if (photo.share.expiresInHours > 48) {
    problems.push({ blobName: photo.blobName, item: "share expiry", fix: "shorten SAS expiry for temporary construction photo review" });
  }
}

if (problems.length > 0) {
  console.table(problems);
  process.exitCode = 1;
} else {
  console.log("Construction photo ledger checklist passed.");
}

Pitfall: Common Failure Cases

The first failure is forcing every detail into the filename. Split the blob name, tags, metadata, and CSV. The second failure is putting private labels into tags. Use internal project IDs. The third failure is a long-lived broad shared URL. Use read-only, short expiry, and narrow scope. The fourth failure is using one retention rule for handover photos, warranty photos, accident photos, and temporary chat imports.

FAQ

Q. Can all photos live in one container?

A. Often yes at the beginning. Compare containers or prefixes when permissions and retention diverge.

Q. What belongs in Blob index tags?

A. Search keys: projectId, phase, location, status, and publicOk. Use metadata for support notes.

Q. Are SAS URLs safe?

A. They are useful for temporary review when read-only, short-lived, and narrow in scope.

Q. What should the team do today?

A. Pick one recent site and check one hundred photos for blob name, projectId, phase, location, status, and publicOk.

Training And Consultation Signal

Measure search time, resend requests, empty CSV fields, photos stopped before submission, expired shared links, and inquiry rate. If those numbers hurt, photo-ledger design and Blob Storage permissions are a fit for ClaudeCodeLab Training.

What I Verified

I checked Microsoft Learn references for Blob Storage, naming, Blob index tags, lifecycle management, soft delete, and SAS. I also checked the CTA, executable JavaScript, internal link, external links, locale coverage, and queue removal.