tigerzplace/fap-facebookautoposter

1. This is a Chrome extension, not a standalone web app. The runtime is split across extension pages (popup.html, background.html, frame.html), a content script injected into Facebook pages, and a set of shared “core” modules under scripts/core.

2. The central user-facing surface is the dashboard UI. pages/popup.html opens the extension experience, and the dashboard logic in scripts/core/dashboard.js drives the campaign builder: group selection, post composition, delay settings, image selection, campaign loading/saving, and start/pause/resume controls.

3. Facebook page interaction is handled separately from the UI. scripts/content.js and scripts/core/fb.js are the automation layer that read and manipulate Facebook’s DOM in the current tab, so posting happens through the browser interface rather than a public Facebook API.

4. The posting workflow is orchestration-heavy. The dashboard sends a campaign to the background/orchestration layer, which sequences posts one group at a time, applies wait times, tracks progress, and coordinates retries, pause/resume, and completion handling.

5. The background subsystem lives under scripts/background/ and is likely responsible for persistent extension behavior: background.js as the long-lived coordinator, plus fix.js and get_host.js for host/tab handling and reliability fixes. This is where cross-tab control and single-instance protection would live.

6. Image posting is its own pipeline. scripts/core/imageUpload.js handles file selection, upload progress, preview state, and re-upload on retry. It is integrated into the campaign flow so the same image can be attached across multiple group posts.

7. Link preview and post composition are managed in the core layer. scripts/core/api.js, scripts/core/functions.js, and scripts/core/frame.js appear to support shared utilities, remote preview fetching, and helper-frame behavior used by the dashboard/posting flow.

8. Campaign state is a first-class concept. The README features map to logic for saved campaigns, saved group lists, multiple post variants, delay presets, smart delay recommendations, and post-run summaries. These are likely persisted locally via extension storage rather than a backend.

9. The extension also has a small external-service boundary. scripts/core/terms.js and scripts/core/api.js suggest calls to Tigerzplace services for licensing/activation and possibly feature gating or metadata, while scripts/ads.json looks like remote/config-driven promotional content.

10. The data flow is: user configures a campaign in the dashboard → campaign state is handed to the background/orchestrator → the orchestrator drives the Facebook automation layer on the active tab → success/failure and direct post URLs are streamed back to the dashboard for logs, counters, and the final summary modal.

11. The static assets and styles are purely presentation concerns. assets/ contains icons, images, and logos; styles/ contains the extension UI styling. They do not affect the automation architecture, but they support the dashboard and licensing pages.

12. The documentation under docs/ is operational rather than runtime logic. It provides tutorials, release notes, and Git/license guidance, which is useful context for understanding intended workflows but not part of the execution path.