Skip to content
ZajLibrary
prod e051e98
Browse

2 · Survey & brand profile

TL;DR

Section titled “TL;DR”

Objective — do the read-only homework that unblocks every later task: a capabilities inventory (editable vs hardcoded vs tier-gated), a vendor-docs digest with the APP_ENV scan, and a one-page brand profile — so pages 3–8 act on facts, not guesses.

Background

Section titled “Background”

Before you change a single setting, do two pieces of read-only homework so every later task acts on facts instead of guesses:

  1. Capabilities discovery — what this exact vendor build exposes in the panel, hides in code, or gates behind a Pro tier.
  2. Brand profile — the one-page source of truth for name, colours, timezone, plans, and legal posture.

Both are write-once artifacts. They’re the input to pages 3–8; spending 90 minutes here removes hours of mid-task ambiguity and re-work.

flowchart LR
    subgraph DISCOVER["Capabilities discovery (read-only)"]
        D1["Vendor docs"]
        D2["Panel crawl"]
        D3["Code inspection"]
    end
    DISCOVER --> CAP["vendor-capabilities.md<br/>+ prerequisite matrix"]
    DOCS["Vendor docs digest<br/>(6 sources + APP_ENV scan)"] --> BRAND["Brand profile<br/>(_CUSTOMIZATIONS.md)"]
    CAP --> BRAND
    BRAND --> LATER["Every Phase 6 task<br/>reads these, never re-investigates"]

Steps

Section titled “Steps”

1. Run capabilities discovery (do this first)

Section titled “1. Run capabilities discovery (do this first)”

CodeCanyon vendors vary wildly in what’s admin-editable versus hardcoded, which custom pages and menus the panel supports, which feature flags live in .env vs the database, and which whole modules (Landing Site, Blog, GDPR, Referrals) ship enabled vs gated behind a Pro tier. Produce one comprehensive inventory now — Admin-Local/1-Project/1-ProjectInfo/vendor-capabilities.md — and every later task consults it instead of re-discovering.

Run all three sources. No single source is sufficient: vendor docs lag the code, the panel hides features behind menus, and code search misses the panel’s visual tabs.

SourceHowWhat it reveals
1 · Vendor docs_Source/ PDFs/README, the CodeCanyon item page, the vendor support portal (froiden.freshdesk.com, docs.workdo.io…)documented modules, default admin URL, gotchas
2 · Panel crawllog in, walk every sidebar item + tab + sub-page (Playwright or manual), screenshot key config pagesthe real, live feature surface (most authoritative)
3 · Code inspectionthe greps belowroutes, settings tables, upload surface, feature flags

  1. Inspect the code surface — routes, settings tables, uploads, feature flags, dynamic pages.

    Terminal window
    # Enumerate admin routes
    grep -rn "Route::" routes/panel.php routes/web.php routes/admin.php 2>/dev/null
    php artisan route:list --name=admin          # reflects live registration
    

    # Admin controllers + Livewire components
    ls app/Livewire/Admin/ app/Http/Controllers/Admin/ 2>/dev/null
    

    # Settings tables — the source of truth for admin-editable config
    mysql -u[DB_USER] -p -e "SHOW TABLES LIKE '%settings%'" [DB_NAME]
    

    # File-upload surface (logos, favicons), feature flags, dynamic pages
    grep -rn "Storage::disk\|config('filesystems" config/ app/ 2>/dev/null | head -50
    grep -rn "'enabled' =>\|feature_" config/ 2>/dev/null
    grep -rn "Page::\|DynamicPage\|CustomPage" app/ 2>/dev/null
    # Expected: admin routes, controller/Livewire listings, settings tables, and the upload/flag surface
    • ✅ Routes, settings tables, upload surface, and feature flags are captured from the code.

  2. Record the audience of every settings page — operator-level vs tenant-level.

    • ✅ Each settings page is labelled operator-level or tenant-level before being recorded.

Capture the output: mkdir -p Admin-Local/1-Project/1-ProjectInfo/screenshots, copy the discovery template to vendor-capabilities.md and fill every section — write not applicable or needs investigation (with a note) rather than leaving a blank — then verify and commit.

  1. Verify the inventory is substantial — under ~100 lines almost always means you skipped sections.

    Terminal window
    test -f Admin-Local/1-Project/1-ProjectInfo/vendor-capabilities.md \
      && wc -l Admin-Local/1-Project/1-ProjectInfo/vendor-capabilities.md
    # Expected: the file exists and is well over ~100 lines
    • ✅ The file exists and is substantial; then commit it (doc + screenshots).

The template ships a Phase 6/7/8 task prerequisite matrix — one row per downstream task, each mapped to the single question that task needs answered (e.g. “Does the vendor ship a built-in cookie banner?”). Every row must have a specific, non-empty answer before you move on. Downstream tasks read their row; they are forbidden from re-investigating. A blank row at task-run time is a discovery bug, not a downstream responsibility. A good answer is specific: “Yes — admin path Admin > Settings > GDPR; blade partials/cookie-consent.blade.php; seeded on by default.” A bad answer is “yes.”

  1. Confirm the matrix has no unanswered rows.

    Terminal window
    grep -c "needs investigation\|TODO\|TBD" \
      Admin-Local/1-Project/1-ProjectInfo/vendor-capabilities.md   # ideally 0
    # Expected: 0 — no blank/"needs investigation" rows remain
    • ✅ The count is 0; every matrix row has a filled answer cell.

2. Review vendor docs and build the digest

Section titled “2. Review vendor docs and build the digest”

CodeCanyon scripts ship vendor-authored docs that are often richer than any generic guide — exact panel layout, required env vars, common gotchas. Reading them first takes ~30 minutes and saves hours. Docs live in up to six places; scan local (cheap) first, then fetch remote.

#SourceFind it with
1Bundled _Source/ PDFs/READMEfind _Source/ -type f \( -iname '*.pdf' -o -iname 'readme*' -o -iname 'install*' \)
2In-repo /docs/ folderfind . -maxdepth 3 -type d -iname 'docs' -not -path './vendor/*'
3CodeCanyon item pagethe item URL in ProjectCard.md — fetch via Playwright (JS-rendered)
4Author portfolioclick the author name → /user/<slug>/portfolio (identifies the vendor family)
5Hosted docs sitedocs.workdo.io, froiden.freshdesk.com, help.iqonic.design
6External add-on marketplaceworkdo.io/product-category/dash-saas-add-ons/, infyom.com/addons/ — the one most people miss

Record every discovered URL in _CUSTOMIZATIONS.md under ## Vendor Docs Sources (with vendor family + fetch date) so later phases can re-fetch. The digest answers only these questions, and lives under ## Vendor Docs Digest in _CUSTOMIZATIONS.md (≤1 page):

QuestionWhy it matters later
Default admin URL + credentialsPage 3 (rotate credentials)
Panel structure (sidebar + tabs)every “CHECK:” in this phase
Multi-tenant model?changes branding, GDPR, plans
Required .env keys beyond Laravel defaultsemail + payments
Does the vendor hardcode behaviour on APP_ENV?the #1 Phase 6 gotcha — see below
Webhook endpoints per gatewayStripe wiring (page 5)
Email template locationsbranding transactional email
Known “don’t do this” warningssaves stepping on the same rake

This is the single most common Phase 6 gotcha — run the APP_ENV hardcoding scan now so the email and payment pages don’t have to.

  1. Scan for strict-equality checks against a non-standard APP_ENV value.

    Terminal window
    grep -rnE "env\('APP_ENV'\)\s*===?\s*['\"]|config\('app\.env'\)\s*===?\s*['\"]" \
        app/ Modules/ packages/ 2>/dev/null | \
        grep -viE 'local|production|staging|testing' | head -20
    # Expected: any non-standard APP_ENV comparison (e.g. 'codecanyon'/'demo'), or no output
    • ✅ The scan result is recorded in the digest even if “none found”.
Pattern foundAction
env('APP_ENV') === 'codecanyon' in mail/payment providersthe panel for that feature is gated — configure via .env directly; document it
env('APP_ENV') === 'demo' in controllersdemo mode (fake data, disabled writes) — don’t set APP_ENV=demo
!== 'local' / === 'production' gatesstandard Laravel — not a gotcha
Nothing foundvendor uses standard APP_ENV values

3. Fill the project brand profile

Section titled “3. Fill the project brand profile”

The brand profile is the source of truth every later task reads. When page 4 asks “what’s the primary colour?” or page 5 asks “what are the plan tiers?”, the answer is read here — not asked mid-task. Fill the template under ## Project Brand Profile in _CUSTOMIZATIONS.md and keep it terse (link out if a field needs >2 lines).

  1. Fill every section of the brand profile from the brand decisions.

    SectionFields
    Identityapp name, tagline, legal entity, production + staging domains
    Audienceprimary/secondary user, geographic focus, launch language(s)
    Brand voicetone, banned phrases, sample CTA copy
    Visual identityprimary/secondary/accent/neutral hex, heading + body type, logo (light/dark), favicon paths
    App settingstimezone, date format, first day of week, default currency (also sets Stripe currency), default locale
    Legalprivacy + ToS generator, cookie-consent provider, GDPR applicability, DPA needed?
    Payment planstiers + prices, billing cycles, trial length, free-tier limits
    Integrations at launchStripe, SMTP provider, GA4, Sentry, Cloudflare, other
    • ✅ Name, colours, timezone, currency, plan tiers, and legal posture are all recorded.

4. Write the execute-from plan

Section titled “4. Write the execute-from plan”

Combine the docs digest (step 2) and the brand profile (step 3) into a single 1-page execution plan — the thing you (or the agent) actually execute the rest of Phase 6 from. Save it under ## Phase 6 Execution Plan in _CUSTOMIZATIONS.md. After this, every later Phase 6 task becomes “read the row, apply the values” — no mid-task brainstorming.

  1. Build the read-the-row table — one row per remaining Phase 6 task (58–72), pulling each value from the digest or brand profile.

    ## Phase 6 Execution Plan — [PROJECT_NAME]
    

    | Task | Admin location | Values to set | Source |
    |---|---|---|---|
    | 58 Admin creds | /user/profile | Email + generated password (→ credentials.md) | Docs digest |
    | 59 Branding | Settings → App | Logo light/dark, favicon, app name, tagline | Brand profile |
    | 60 SMTP | Settings → Email | Host/port/user, from-name | Phase 4 SMTP creds |
    | 61 Payment gateway | Settings → Payment | Enable Stripe, disable the rest | Brand profile |
    | 67 Theme colors | Settings → Theme | Primary / secondary / accent hex | Brand profile |
    | 72 Plans | Packages | Tiers + prices + cycles | Brand profile |
    | …  | … | … (one row per task 58–72) | … |
    

    **Known gotchas (from the docs digest):** e.g. "enable Modules → Billing before creating plans or the pricing page 404s".
    **Estimated time:** [MUST tasks + SHOULD tasks].
    • ✅ _CUSTOMIZATIONS.md has a ## Phase 6 Execution Plan table with one row per task 58–72, each value sourced from the digest or brand profile.

Checklist

Section titled “Checklist”

Do not mark this step done until every box below is checked.

  • 🤖 Capabilities inventory complete — vendor-capabilities.md exists, is >100 lines, and the prerequisite matrix has zero blank/“needs investigation” rows.
  • 🤖 Audience recorded — operator vs tenant is recorded for every settings page found.
  • 🤖 Docs digest written — vendor docs sources + digest are in _CUSTOMIZATIONS.md, including the APP_ENV scan result.
  • 👤 Brand profile filled — name, colours, timezone, currency, plan tiers, legal posture.
  • 🤖 Execution plan written — ## Phase 6 Execution Plan table in _CUSTOMIZATIONS.md, one row per task 58–72.
  • 🔀 Committed — capabilities doc + screenshots + _CUSTOMIZATIONS.md all committed.

3 · Credentials & branding