Nombres de fotos de obra en Azure Blob Storage

En una empresa de construcción, las fotos de obra dejan de servir cuando llegan como IMG_4821.jpg. La pizarra de obra tiene el número de proyecto, el chat tiene el comentario del encargado y el cliente pide solo las fotos de impermeabilización. Si Azure Blob Storage no guarda un nombre y tags claros, la oficina pierde tiempo buscando. El primer paso es revisar cien fotos recientes y fijar una regla simple.

Key Points

• No dependas del nombre de cámara para la bitácora fotográfica.
• Separa projectId, fase, ubicación, estado, fecha y secuencia.
• Usa Blob index tags para búsqueda y metadata para notas de apoyo.
• Claude Code prepara reglas y tablas; una persona revisa privacidad y aprobación.
• La señal de negocio es tiempo de búsqueda, reenvíos, campos vacíos y tasa de consulta.

Workflow: Photo Ledger Before Upload

Antes de subir fotos, mira la lista real: carpetas, nombres, fecha, fase, ubicación, destino y estado de aprobación. Construcción no necesita magia; necesita que la foto de techo, reparación, antes/después y entrega aparezca sin abrir cinco chats. Claude Code puede convertir esa lista en una tabla de nombres, tags, metadata y CSV de revisión.

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 formación de ClaudeCodeLab.

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.