Repair the Messy Drive

You are taking over a fictional project workspace. Nothing is missing, but the organization and access settings are bad enough that mistakes are likely.

Incident snapshot

My Drive
├── stuff
│   ├── final
│   └── notes
├── Untitled document
├── Screenshot 172.png
├── FINAL
├── school thing
├── presentation FINAL FINAL
└── Copy of Copy of data

Additional evidence:

Your job is not to guess what every mystery file contains. Your job is to design a repair process that does not destroy evidence or widen access while you investigate.

Phase 1 — Freeze assumptions

List what you know and what you do not know.

Example:

• Known: FINAL is currently private and teacher needs read access.
• Unknown: whether FINAL is actually the correct final submission.

Do not rename a file based only on wishful thinking. Open course-safe supplied files or use the scenario description to determine their purpose first.

Phase 2 — Propose the information architecture

Draw a before/after map. Your after-state should include meaningful folders and names. Include a reason for each top-level folder.

A possible design is:

Digital Literacy Project
├── Planning
├── Data
├── Presentation
└── Submission

You may choose another design if retrieval is clear.

Phase 3 — Repair access

For each file in the evidence table, state:

• intended identity/audience;
• required action;
• minimum role;
• current mismatch;
• proposed change.

The repair should preserve required function. Hardening everything to “private” is not a successful fix if the teammate can no longer coauthor the project.

Phase 4 — Retest

Run two tests against your repaired plan:

Retrieval test: Can the intended person identify the correct file from its name and path?

Access test: Can the intended role perform the required action without receiving extra capability?

If working in a live school Drive is not appropriate, perform the test against a teacher-provided sample workspace or your written permission model.

Submit — The Messy Drive Incident

Your evidence packet contains:

1. before/after folder map;
2. renamed-file table with reasons;
3. permission repair matrix;
4. retrieval-test result;
5. access-test result;
6. one remaining uncertainty.

What earns full credit

A strong repair is defensible, not merely neat. It does not invent facts, delete mystery files to make the screen cleaner, grant broad permissions for convenience, or claim success without a retest.

The final sentence should answer: What evidence tells you this Drive is safer and easier to use than the incident snapshot?