Nomear fotos de obra no Azure Blob Storage

Em uma construtora, uma foto chamada IMG_4821.jpg vira problema quando chega a hora do dossiê de entrega. O número da obra está no quadro, a fase está no WhatsApp e o cliente pede apenas as fotos de impermeabilização. Se o Azure Blob Storage recebe tudo sem nomes e tags, o escritório perde tempo procurando. A primeira ação é revisar cem fotos recentes.

Key Points

Não deixe o nome da câmera carregar todo o contexto.
Separe projeto, fase, local, status, data e sequência.
Use Blob index tags para busca e metadata para apoio.
Claude Code prepara regra, CSV e alertas.
Pessoas revisam nomes de clientes, endereços, rostos, placas, contratos e aprovação.

Workflow: Photo Ledger Before Upload

O fluxo começa pela lista de fotos, não pelo portal do Azure. Coloque pasta, nome atual, data, fase, local, destino e status de publicação em uma tabela. Depois peça a Claude Code uma regra de caminho Blob, tags obrigatórias e CSV de revisão.

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 treinamento 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.