ramparte/amplifier-m365-platform
A verifiable M365 integration in 9 days
amplifier-m365-platform is a project built with Amplifier: SharePoint, Teams, and Entra-identity tools for Microsoft 365. It started from an empty repository — here's what building from nothing actually looks like.
Start with the baseline that makes the rest of the story credible.
Commit 9979614 "Initial project setup" (2026-01-15) changed only the .gitignore — 29 insertions, 1 file. There was no source code at the start. This is the true zero baseline the nine-day build grew from.
From that empty repo, look at what shipped.
Across 37 commits and 9 calendar days (2026-01-15 → 2026-01-23), the project built 13 non-test core files for SharePoint, Teams, and an Entra-identity hook — against a real M365 test tenant.
Real, working leverage. But the first build made one assumption that didn't hold.
On-Behalf-Of (OBO) exchanges a user's token so a service can act as that user — but it needs that interactive user in the loop. It can't let an autonomous or daemon agent act as a specific user without interactive sign-in. For multi-agent scenarios, OBO-only was a real gap.
The fix wasn't a rewrite — it was widening the auth model.
A single AuthMode enum now carries three flows. OBO stays the default — the change is backward compatible — while ROPC and SERVICE_PRINCIPAL cover the cases OBO can't reach.
Who decided to widen it? Humans, steering through merged PRs.
Marc Goodner authored all 4 merged PRs (login robotdad); Sam Schillace led with 28 of the 37 commits. Amplifier is attributed on 5 commits ("Generated with Amplifier"), 4 also "Co-Authored-By."
Under that direction, the auth model widened itself — the deck's high point.
On 2026-01-21, PR #1 (branch feat/ropc-auth-support, commit 8b1f9a5) added ROPC "as an alternative to OBO… enabling daemon apps and multi-agent scenarios where agents need to act as specific users without interactive authentication." The build recognized its own auth model was too narrow — and widened it, backward-compatibly.
Did the corrected integration actually work? It was put on a real tenant.
On 2026-01-23, end-to-end operational validation ran against a real M365 tenant: 4 of 5 checks PASS, 1 PARTIAL. A build that started from an empty .gitignore corrected its own auth model and produced a genuinely validated result — honest partial included.
Zero to validated M365 integration — with a self-correction you can check in the git log.
Verification: PASS
Data as of: 2026-01-23 (repo HEAD a864f28) · Feature status: Active
Repository: git@github.com:ramparte/amplifier-m365-platform.git (branch master, HEAD a864f28). Every claim independently re-derived via git / gh / find / grep / sed / wc.
Commands run:
git remote -v && git branch --show-current && git log -1 --format='%H | %s'git show 9979614 --stat (29 insertions, 1 file: .gitignore)find src/amplifier_tool_teams src/amplifier_tool_sharepoint src/amplifier_hook_entra_identity -name '*.py' ... | wc -l (13)sed -n '18,25p' src/amplifier_tool_sharepoint/auth.py (OBO / ROPC / SERVICE_PRINCIPAL)git show 8b1f9a5 & gh pr view 1 --json title,body (2026-01-21)git log --oneline | wc -l (37) ; git shortlog -sne --all (Sam Schillace 28, Marc Goodner 9)gh pr list --state merged --json number,title,author,headRefName,mergedAt (4, all robotdad)git log --format=%B | grep -c 'Generated with .*Amplifier' (5) ; Co-Authored-By (4)sed -n '1,55p' FINAL_E2E_EVIDENCE_REPORT.md (2026-01-23: 4/5 PASS, 1 PARTIAL)Gaps / honesty notes: "Hackathon", multiple external participants, and "five agent citizens" framings are NOT repo-verifiable and are excluded; SharePoint direct call is a PARTIAL, reported as such.
Primary contributors: Sam Schillace (28/37 commits) · Marc Goodner (9 commits, all 4 merged PRs).