diff --git a/README.md b/README.md index 7ba878b..69c9115 100644 --- a/README.md +++ b/README.md @@ -67,12 +67,18 @@ Staff should begin with First run and Daily workflow. Administrators should also | Native desktop source version | 1.8.0-1 | | Candidate hashes | [SHA-256 checksums](https://github.com/townlight/townlight/releases/download/townlight-windows-v1.8.0.1/SHA256SUMS-Windows-1.8.0.1.txt) and [Windows acceptance summary](https://github.com/townlight/townlight/releases/download/townlight-windows-v1.8.0.1/ACCEPTANCE-Windows-1.8.0.1.md) | | Current owned software license | AGPL-3.0-only | -| Acceptance composition | Fresh Windows x64 profile; inspections-preview; Station configured separately | +| Acceptance composition | Windows x64 fresh install and upgrade from 1.7.2.1. Select the full profile. Station uses separate configuration. | Start a new installation with an empty database and fresh Windows profile. For an upgrade from Windows 1.7.2.1, keep the existing profile. The approved profile path is `%LOCALAPPDATA%\CivicSuite`. Keep existing profiles and backups. ## First run +**Upgrade from 1.7.2.1.** For the tested upgrade from 1.7.2.1, back up city data and settings, close Townlight, run the signed Windows 1.8.0.1 MSI, and reopen Townlight under the same Windows account with its existing profile. Keep the existing `%LOCALAPPDATA%\CivicSuite` directory. Upgrade paths from versions older than 1.7.2.1 are unverified. Station uses its separately configured service. + +### Fresh installation + +Run the signed Windows 1.8.0.1 MSI and use an empty database and a new Townlight profile for first run. + 1. Download the signed MSI, matching source companion and checksums from the [public Windows release](https://github.com/townlight/townlight/releases/tag/townlight-windows-v1.8.0.1). 2. Verify the MSI hash and Authenticode publisher before installation. See the [Windows acceptance summary](https://github.com/townlight/townlight/releases/download/townlight-windows-v1.8.0.1/ACCEPTANCE-Windows-1.8.0.1.md) for the tested setup. 3. Launch Townlight under the intended named Windows account. Choose the storage folders. Select **Townlight Inspections candidate** (`inspections-preview`) for the bounded desktop composition, including Access and Notice. A narrower default selection will not expose all workspaces. @@ -198,7 +204,7 @@ Source contracts: `townlight_runtime/zoning_bridge.py`, `townlight_zoning/main.p ### Runtime and storage -The accepted package targets **Windows x64 fresh installation**. Its native shell uses **Rust 2021, Tauri 2 and Microsoft WebView2**; browser assets are JavaScript built with **Vite 8.1.6**. This describes the native desktop frontend; Station has a separate React operator, specified below or in its product manual. Canonical business workflows use bundled **CPython 3.13.5, FastAPI, Pydantic, SQLAlchemy and Alembic**, with **PostgreSQL 17 / PostGIS** and managed original files. The installed runtime tested here contains FastAPI 0.162.0. Package minimum Python requirements can differ from the bundled executable; the metadata reference preserves both. No stack rewrite is implied by the beta label. +The accepted package supports Windows x64 fresh installation and upgrade from 1.7.2.1. Its native shell uses **Rust 2021, Tauri 2 and Microsoft WebView2**; browser assets are JavaScript built with **Vite 8.1.6**. This describes the native desktop frontend; Station has a separate React operator, specified below or in its product manual. Canonical business workflows use bundled **CPython 3.13.5, FastAPI, Pydantic, SQLAlchemy and Alembic**, with **PostgreSQL 17 / PostGIS** and managed original files. The installed runtime tested here contains FastAPI 0.162.0. Package minimum Python requirements can differ from the bundled executable; the metadata reference preserves both. No stack rewrite is implied by the beta label. The native transport is fixed to loopback `127.0.0.1:15480`; PostgreSQL uses the configured local runtime port (default `15432`). Optional local model service defaults to `127.0.0.1:15434`. Those are deployment defaults, not internet endpoints. The runtime has health, module and readiness endpoints; readiness is stronger than process existence. The task queue is the existing local Core task infrastructure, not an assertion that a separate Redis service is required for this desktop composition. @@ -317,7 +323,7 @@ Use protected local folders, account permissions and credential storage. Never i Save work and use Core’s canonical **Backup Now** before maintenance. That operation stops writers. Preserve the coherent profile/database/document backup and its receipt, then use **Start** to resume. A source export is not a full backup. -Use **Restore Latest Backup** through the supported controls. If the result says **Restore needs service start**, use **Start**, then **Check**, and reopen a known record. Do not repeat restore merely because services need to start. The fresh-profile acceptance verified that a fulfilled request survived restore and a post-backup marker did not. +Use **Restore Latest Backup** through the supported controls. If the result says **Restore needs service start**, use **Start**, then **Check**, and reopen a known record. Do not repeat restore merely because services need to start. The [Windows 1.6.0.1 Beta 1 fresh-install acceptance](https://github.com/townlight/townlight/releases/tag/townlight-beta-1) verified that a fulfilled request survived restore and a post-backup marker did not. Keep Station’s dedicated database and media evidence together in its own backup. Core’s native-profile backup must not be assumed to include an external Station data directory. Stop writers during a coordinated backup. Preserve failed media attempts and logs. @@ -338,15 +344,13 @@ On failure, record the time, selected composition, component/installer versions ## Verified workflows and limits +The table records selected synthetic workflows from the original [Windows 1.6.0.1 Beta 1](https://github.com/townlight/townlight/releases/tag/townlight-beta-1) Sandbox run. Station’s later delivery has [separate Windows 1.6.0.1 acceptance](https://github.com/townlight/townlight/releases/tag/townlight-beta-1-station-delivery). See the [Windows 1.8.0.1 acceptance summary](https://github.com/townlight/townlight/releases/download/townlight-windows-v1.8.0.1/ACCEPTANCE-Windows-1.8.0.1.md) for the workflows and upgrade path exercised on the current MSI. + | Product | Recorded result | Precisely exercised | |----|----|----| | Zoning | PASS | GeoJSON/PostGIS import, cited dimensional rule, parcel answer, staff review/history/snapshot and native workspace. | -These results come from the identified signed candidate’s fresh normal-profile Sandbox exercise: real native IPC/HTTP/PostgreSQL and selected headless controls. All accounts, source bundles and media were synthetic. The guest install/uninstall and recovery passed, and the owned Sandbox stopped. No host installed application or standalone CivicCast was changed. This documentation task reuses those receipts; it does not claim a new software acceptance run. - -See the [Windows acceptance summary](https://github.com/townlight/townlight/releases/download/townlight-windows-v1.8.0.1/ACCEPTANCE-Windows-1.8.0.1.md) for this MSI. The historical [evidence index](https://townlight.github.io/reference/sandbox-evidence-index.json) applies to its original build. - -The limits remain: actual city field acceptance and equipment/network commissioning; Station automatic provisioning/SCM commissioning; every UI/role combination; field recognition accuracy; and historical in-place upgrades are not certified. They are not five invented feature requirements. Fresh-install controlled beta handoff remains the accepted scope. This package makes no city-deployment, publication or general-availability claim. +The Windows 1.8.0.1 acceptance covers the tested installation paths and selected synthetic workflows, including Boards & Commissions, Contracts, and Procurement. Earlier results apply to their original builds. City field acceptance, physical equipment and network commissioning, Station automatic provisioning, and comprehensive UI and role coverage remain outside the 1.8.0.1 checks. ## Terms of service and license @@ -374,7 +378,7 @@ Staff verify the jurisdiction, source currency, permissions, citations and propo ### Beta operation and recovery -Use the identified candidate in its supported fresh-install scope. Preserve backups and original evidence. Test physical equipment and chosen network/service configuration before relying on them. The supplied acceptance describes selected synthetic workflows, not every screen, vendor, field condition or upgrade. Operators decide whether a particular deployment meets their own operational obligations. +Windows 1.8.0.1 was tested for fresh installation and in-place upgrade from 1.7.2.1. Upgrade paths from versions older than 1.7.2.1 are unverified. Station uses its separately configured service. Keep backups and original evidence. Test your physical equipment and network and service configuration before relying on them. See the [acceptance summary](https://github.com/townlight/townlight/releases/download/townlight-windows-v1.8.0.1/ACCEPTANCE-Windows-1.8.0.1.md) for the tested paths. ### Warranty and liability @@ -484,9 +488,7 @@ python -c "import townlight_zoning; from importlib.metadata import version; prin ``` Expected principal import: `townlight_zoning`; expected distribution version: -`0.2.3`. Use a fresh empty database/profile for workflow testing. Existing -city data and the previous release remain untouched; no in-place upgrade or -old-import compatibility shim is supplied. +`0.2.3`. For standalone component workflow testing, use a fresh empty database and profile. These component commands do not perform a Windows MSI upgrade. See First run for the supported Windows upgrade. ## License and responsible use diff --git a/README.txt b/README.txt index 83e5ad9..7486e87 100644 --- a/README.txt +++ b/README.txt @@ -1,7 +1,7 @@ Windows x64 Beta 1 · MSI 1.8.0.1 -The signed Windows x64 beta 1.8.0.1 updates installer metadata while -preserving the accepted signed application/runtime cabinet. +The signed Windows x64 beta 1.8.0.1 adds the three staff workspaces and +automatically refreshes the bundled runtime when upgrading from 1.7.2.1. - Townlight Zoning Manual - Contents @@ -70,22 +70,35 @@ included with the same documentation companion. Beta identity Identity Value - -------------------------------- ------------------------------------------------------------------------------- + -------------------------------- ------------------------------------------------------------------------------------------------------------------- Documentation Townlight Beta 1 naming, Access and Notice candidate - Windows MSI version 1.8.0.1 + Windows MSI version 1.8.0.1 Product component townlight-zoning 0.2.3 Principal import package townlight_zoning Native desktop source version 1.8.0-1 Candidate hashes SHA-256 checksums and Windows acceptance summary Current owned software license AGPL-3.0-only - Acceptance composition Fresh Windows x64 profile; inspections-preview; Station configured separately + Acceptance composition Windows x64 fresh install and upgrade from 1.7.2.1. Select the full profile. Station uses separate configuration. -Use an empty database and fresh Windows profile. The installer refuses -legacy profile initialization. The approved profile path is -%LOCALAPPDATA%\CivicSuite. Keep existing profiles and backups. +Start a new installation with an empty database and fresh Windows +profile. For an upgrade from Windows 1.7.2.1, keep the existing profile. +The approved profile path is %LOCALAPPDATA%\CivicSuite. Keep existing +profiles and backups. First run +Upgrade from 1.7.2.1. For the tested upgrade from 1.7.2.1, back up city +data and settings, close Townlight, run the signed Windows 1.8.0.1 MSI, +and reopen Townlight under the same Windows account with its existing +profile. Keep the existing %LOCALAPPDATA%\CivicSuite directory. Upgrade +paths from versions older than 1.7.2.1 are unverified. Station uses its +separately configured service. + +Fresh installation + +Run the signed Windows 1.8.0.1 MSI and use an empty database and a new +Townlight profile for first run. + 1. Download the signed MSI, matching source companion and checksums from the public Windows release. 2. Verify the MSI hash and Authenticode publisher before installation. @@ -283,16 +296,16 @@ Technical specifications Runtime and storage -The accepted package targets Windows x64 fresh installation. Its native -shell uses Rust 2021, Tauri 2 and Microsoft WebView2; browser assets are -JavaScript built with Vite 8.1.6. This describes the native desktop -frontend; Station has a separate React operator, specified below or in -its product manual. Canonical business workflows use bundled CPython -3.13.5, FastAPI, Pydantic, SQLAlchemy and Alembic, with PostgreSQL 17 / -PostGIS and managed original files. The installed runtime tested here -contains FastAPI 0.162.0. Package minimum Python requirements can differ -from the bundled executable; the metadata reference preserves both. No -stack rewrite is implied by the beta label. +The accepted package supports Windows x64 fresh installation and upgrade +from 1.7.2.1. Its native shell uses Rust 2021, Tauri 2 and Microsoft +WebView2; browser assets are JavaScript built with Vite 8.1.6. This +describes the native desktop frontend; Station has a separate React +operator, specified below or in its product manual. Canonical business +workflows use bundled CPython 3.13.5, FastAPI, Pydantic, SQLAlchemy and +Alembic, with PostgreSQL 17 / PostGIS and managed original files. The +installed runtime tested here contains FastAPI 0.162.0. Package minimum +Python requirements can differ from the bundled executable; the metadata +reference preserves both. No stack rewrite is implied by the beta label. The native transport is fixed to loopback 127.0.0.1:15480; PostgreSQL uses the configured local runtime port (default 15432). Optional local @@ -519,8 +532,8 @@ a full backup. Use Restore Latest Backup through the supported controls. If the result says Restore needs service start, use Start, then Check, and reopen a known record. Do not repeat restore merely because services need to -start. The fresh-profile acceptance verified that a fulfilled request -survived restore and a post-backup marker did not. +start. The Windows 1.6.0.1 Beta 1 fresh-install acceptance verified that +a fulfilled request survived restore and a post-backup marker did not. Keep Station’s dedicated database and media evidence together in its own backup. Core’s native-profile backup must not be assumed to include an @@ -549,28 +562,21 @@ Troubleshooting Verified workflows and limits +The table records selected synthetic workflows from the original Windows +1.6.0.1 Beta 1 Sandbox run. Station’s later delivery has separate +Windows 1.6.0.1 acceptance. See the Windows 1.8.0.1 acceptance summary +for the workflows and upgrade path exercised on the current MSI. + Product Recorded result Precisely exercised --------- ----------------- -------------------------------------------------------------------------------------------------------------------- Zoning PASS GeoJSON/PostGIS import, cited dimensional rule, parcel answer, staff review/history/snapshot and native workspace. -These results come from the identified signed candidate’s fresh -normal-profile Sandbox exercise: real native IPC/HTTP/PostgreSQL and -selected headless controls. All accounts, source bundles and media were -synthetic. The guest install/uninstall and recovery passed, and the -owned Sandbox stopped. No host installed application or standalone -CivicCast was changed. This documentation task reuses those receipts; it -does not claim a new software acceptance run. - -See the Windows acceptance summary for this MSI. The historical evidence -index applies to its original build. - -The limits remain: actual city field acceptance and equipment/network -commissioning; Station automatic provisioning/SCM commissioning; every -UI/role combination; field recognition accuracy; and historical in-place -upgrades are not certified. They are not five invented feature -requirements. Fresh-install controlled beta handoff remains the accepted -scope. This package makes no city-deployment, publication or -general-availability claim. +The Windows 1.8.0.1 acceptance covers the tested installation paths and +selected synthetic workflows, including Boards & Commissions, Contracts, +and Procurement. Earlier results apply to their original builds. City +field acceptance, physical equipment and network commissioning, Station +automatic provisioning, and comprehensive UI and role coverage remain +outside the 1.8.0.1 checks. Terms of service and license @@ -635,12 +641,12 @@ amounts do not become a new authoritative calculation. Beta operation and recovery -Use the identified candidate in its supported fresh-install scope. -Preserve backups and original evidence. Test physical equipment and -chosen network/service configuration before relying on them. The -supplied acceptance describes selected synthetic workflows, not every -screen, vendor, field condition or upgrade. Operators decide whether a -particular deployment meets their own operational obligations. +Windows 1.8.0.1 was tested for fresh installation and in-place upgrade +from 1.7.2.1. Upgrade paths from versions older than 1.7.2.1 are +unverified. Station uses its separately configured service. Keep backups +and original evidence. Test your physical equipment and network and +service configuration before relying on them. See the acceptance summary +for the tested paths. Warranty and liability @@ -774,9 +780,9 @@ matching pinned source and verify its SHA256 manifest: python -c "import townlight_zoning; from importlib.metadata import version; print(version('townlight-zoning'))" Expected principal import: townlight_zoning; expected distribution -version: 0.2.3. Use a fresh empty database/profile for workflow testing. -Existing city data and the previous release remain untouched; no -in-place upgrade or old-import compatibility shim is supplied. +version: 0.2.3. For standalone component workflow testing, use a fresh +empty database and profile. These component commands do not perform a +Windows MSI upgrade. See First run for the supported Windows upgrade. License and responsible use diff --git a/USER-MANUAL.docx b/USER-MANUAL.docx index c884ef7..517d4a5 100644 Binary files a/USER-MANUAL.docx and b/USER-MANUAL.docx differ diff --git a/USER-MANUAL.md b/USER-MANUAL.md index f73cf7c..200ec6b 100644 --- a/USER-MANUAL.md +++ b/USER-MANUAL.md @@ -67,12 +67,18 @@ Staff should begin with First run and Daily workflow. Administrators should also | Native desktop source version | 1.8.0-1 | | Candidate hashes | [SHA-256 checksums](https://github.com/townlight/townlight/releases/download/townlight-windows-v1.8.0.1/SHA256SUMS-Windows-1.8.0.1.txt) and [Windows acceptance summary](https://github.com/townlight/townlight/releases/download/townlight-windows-v1.8.0.1/ACCEPTANCE-Windows-1.8.0.1.md) | | Current owned software license | AGPL-3.0-only | -| Acceptance composition | Fresh Windows x64 profile; inspections-preview; Station configured separately | +| Acceptance composition | Windows x64 fresh install and upgrade from 1.7.2.1. Select the full profile. Station uses separate configuration. | Start a new installation with an empty database and fresh Windows profile. For an upgrade from Windows 1.7.2.1, keep the existing profile. The approved profile path is `%LOCALAPPDATA%\CivicSuite`. Keep existing profiles and backups. ## First run +**Upgrade from 1.7.2.1.** For the tested upgrade from 1.7.2.1, back up city data and settings, close Townlight, run the signed Windows 1.8.0.1 MSI, and reopen Townlight under the same Windows account with its existing profile. Keep the existing `%LOCALAPPDATA%\CivicSuite` directory. Upgrade paths from versions older than 1.7.2.1 are unverified. Station uses its separately configured service. + +### Fresh installation + +Run the signed Windows 1.8.0.1 MSI and use an empty database and a new Townlight profile for first run. + 1. Download the signed MSI, matching source companion and checksums from the [public Windows release](https://github.com/townlight/townlight/releases/tag/townlight-windows-v1.8.0.1). 2. Verify the MSI hash and Authenticode publisher before installation. See the [Windows acceptance summary](https://github.com/townlight/townlight/releases/download/townlight-windows-v1.8.0.1/ACCEPTANCE-Windows-1.8.0.1.md) for the tested setup. 3. Launch Townlight under the intended named Windows account. Choose the storage folders. Select **Townlight Inspections candidate** (`inspections-preview`) for the bounded desktop composition, including Access and Notice. A narrower default selection will not expose all workspaces. @@ -198,7 +204,7 @@ Source contracts: `townlight_runtime/zoning_bridge.py`, `townlight_zoning/main.p ### Runtime and storage -The accepted package targets **Windows x64 fresh installation**. Its native shell uses **Rust 2021, Tauri 2 and Microsoft WebView2**; browser assets are JavaScript built with **Vite 8.1.6**. This describes the native desktop frontend; Station has a separate React operator, specified below or in its product manual. Canonical business workflows use bundled **CPython 3.13.5, FastAPI, Pydantic, SQLAlchemy and Alembic**, with **PostgreSQL 17 / PostGIS** and managed original files. The installed runtime tested here contains FastAPI 0.162.0. Package minimum Python requirements can differ from the bundled executable; the metadata reference preserves both. No stack rewrite is implied by the beta label. +The accepted package supports Windows x64 fresh installation and upgrade from 1.7.2.1. Its native shell uses **Rust 2021, Tauri 2 and Microsoft WebView2**; browser assets are JavaScript built with **Vite 8.1.6**. This describes the native desktop frontend; Station has a separate React operator, specified below or in its product manual. Canonical business workflows use bundled **CPython 3.13.5, FastAPI, Pydantic, SQLAlchemy and Alembic**, with **PostgreSQL 17 / PostGIS** and managed original files. The installed runtime tested here contains FastAPI 0.162.0. Package minimum Python requirements can differ from the bundled executable; the metadata reference preserves both. No stack rewrite is implied by the beta label. The native transport is fixed to loopback `127.0.0.1:15480`; PostgreSQL uses the configured local runtime port (default `15432`). Optional local model service defaults to `127.0.0.1:15434`. Those are deployment defaults, not internet endpoints. The runtime has health, module and readiness endpoints; readiness is stronger than process existence. The task queue is the existing local Core task infrastructure, not an assertion that a separate Redis service is required for this desktop composition. @@ -317,7 +323,7 @@ Use protected local folders, account permissions and credential storage. Never i Save work and use Core’s canonical **Backup Now** before maintenance. That operation stops writers. Preserve the coherent profile/database/document backup and its receipt, then use **Start** to resume. A source export is not a full backup. -Use **Restore Latest Backup** through the supported controls. If the result says **Restore needs service start**, use **Start**, then **Check**, and reopen a known record. Do not repeat restore merely because services need to start. The fresh-profile acceptance verified that a fulfilled request survived restore and a post-backup marker did not. +Use **Restore Latest Backup** through the supported controls. If the result says **Restore needs service start**, use **Start**, then **Check**, and reopen a known record. Do not repeat restore merely because services need to start. The [Windows 1.6.0.1 Beta 1 fresh-install acceptance](https://github.com/townlight/townlight/releases/tag/townlight-beta-1) verified that a fulfilled request survived restore and a post-backup marker did not. Keep Station’s dedicated database and media evidence together in its own backup. Core’s native-profile backup must not be assumed to include an external Station data directory. Stop writers during a coordinated backup. Preserve failed media attempts and logs. @@ -338,15 +344,13 @@ On failure, record the time, selected composition, component/installer versions ## Verified workflows and limits +The table records selected synthetic workflows from the original [Windows 1.6.0.1 Beta 1](https://github.com/townlight/townlight/releases/tag/townlight-beta-1) Sandbox run. Station’s later delivery has [separate Windows 1.6.0.1 acceptance](https://github.com/townlight/townlight/releases/tag/townlight-beta-1-station-delivery). See the [Windows 1.8.0.1 acceptance summary](https://github.com/townlight/townlight/releases/download/townlight-windows-v1.8.0.1/ACCEPTANCE-Windows-1.8.0.1.md) for the workflows and upgrade path exercised on the current MSI. + | Product | Recorded result | Precisely exercised | |----|----|----| | Zoning | PASS | GeoJSON/PostGIS import, cited dimensional rule, parcel answer, staff review/history/snapshot and native workspace. | -These results come from the identified signed candidate’s fresh normal-profile Sandbox exercise: real native IPC/HTTP/PostgreSQL and selected headless controls. All accounts, source bundles and media were synthetic. The guest install/uninstall and recovery passed, and the owned Sandbox stopped. No host installed application or standalone CivicCast was changed. This documentation task reuses those receipts; it does not claim a new software acceptance run. - -See the [Windows acceptance summary](https://github.com/townlight/townlight/releases/download/townlight-windows-v1.8.0.1/ACCEPTANCE-Windows-1.8.0.1.md) for this MSI. The historical [evidence index](https://townlight.github.io/reference/sandbox-evidence-index.json) applies to its original build. - -The limits remain: actual city field acceptance and equipment/network commissioning; Station automatic provisioning/SCM commissioning; every UI/role combination; field recognition accuracy; and historical in-place upgrades are not certified. They are not five invented feature requirements. Fresh-install controlled beta handoff remains the accepted scope. This package makes no city-deployment, publication or general-availability claim. +The Windows 1.8.0.1 acceptance covers the tested installation paths and selected synthetic workflows, including Boards & Commissions, Contracts, and Procurement. Earlier results apply to their original builds. City field acceptance, physical equipment and network commissioning, Station automatic provisioning, and comprehensive UI and role coverage remain outside the 1.8.0.1 checks. ## Terms of service and license @@ -374,7 +378,7 @@ Staff verify the jurisdiction, source currency, permissions, citations and propo ### Beta operation and recovery -Use the identified candidate in its supported fresh-install scope. Preserve backups and original evidence. Test physical equipment and chosen network/service configuration before relying on them. The supplied acceptance describes selected synthetic workflows, not every screen, vendor, field condition or upgrade. Operators decide whether a particular deployment meets their own operational obligations. +Windows 1.8.0.1 was tested for fresh installation and in-place upgrade from 1.7.2.1. Upgrade paths from versions older than 1.7.2.1 are unverified. Station uses its separately configured service. Keep backups and original evidence. Test your physical equipment and network and service configuration before relying on them. See the [acceptance summary](https://github.com/townlight/townlight/releases/download/townlight-windows-v1.8.0.1/ACCEPTANCE-Windows-1.8.0.1.md) for the tested paths. ### Warranty and liability diff --git a/USER-MANUAL.pdf b/USER-MANUAL.pdf index 42d882f..016ef9a 100644 Binary files a/USER-MANUAL.pdf and b/USER-MANUAL.pdf differ diff --git a/USER-MANUAL.txt b/USER-MANUAL.txt index 7587908..9a10abb 100644 --- a/USER-MANUAL.txt +++ b/USER-MANUAL.txt @@ -1,7 +1,7 @@ Windows x64 Beta 1 · MSI 1.8.0.1 -The signed Windows x64 beta 1.8.0.1 updates installer metadata while -preserving the accepted signed application/runtime cabinet. +The signed Windows x64 beta 1.8.0.1 adds the three staff workspaces and +automatically refreshes the bundled runtime when upgrading from 1.7.2.1. - Townlight Zoning Manual - Contents @@ -70,22 +70,35 @@ included with the same documentation companion. Beta identity Identity Value - -------------------------------- ------------------------------------------------------------------------------- + -------------------------------- ------------------------------------------------------------------------------------------------------------------- Documentation Townlight Beta 1 naming, Access and Notice candidate - Windows MSI version 1.8.0.1 + Windows MSI version 1.8.0.1 Product component townlight-zoning 0.2.3 Principal import package townlight_zoning Native desktop source version 1.8.0-1 Candidate hashes SHA-256 checksums and Windows acceptance summary Current owned software license AGPL-3.0-only - Acceptance composition Fresh Windows x64 profile; inspections-preview; Station configured separately + Acceptance composition Windows x64 fresh install and upgrade from 1.7.2.1. Select the full profile. Station uses separate configuration. -Use an empty database and fresh Windows profile. The installer refuses -legacy profile initialization. The approved profile path is -%LOCALAPPDATA%\CivicSuite. Keep existing profiles and backups. +Start a new installation with an empty database and fresh Windows +profile. For an upgrade from Windows 1.7.2.1, keep the existing profile. +The approved profile path is %LOCALAPPDATA%\CivicSuite. Keep existing +profiles and backups. First run +Upgrade from 1.7.2.1. For the tested upgrade from 1.7.2.1, back up city +data and settings, close Townlight, run the signed Windows 1.8.0.1 MSI, +and reopen Townlight under the same Windows account with its existing +profile. Keep the existing %LOCALAPPDATA%\CivicSuite directory. Upgrade +paths from versions older than 1.7.2.1 are unverified. Station uses its +separately configured service. + +Fresh installation + +Run the signed Windows 1.8.0.1 MSI and use an empty database and a new +Townlight profile for first run. + 1. Download the signed MSI, matching source companion and checksums from the public Windows release. 2. Verify the MSI hash and Authenticode publisher before installation. @@ -283,16 +296,16 @@ Technical specifications Runtime and storage -The accepted package targets Windows x64 fresh installation. Its native -shell uses Rust 2021, Tauri 2 and Microsoft WebView2; browser assets are -JavaScript built with Vite 8.1.6. This describes the native desktop -frontend; Station has a separate React operator, specified below or in -its product manual. Canonical business workflows use bundled CPython -3.13.5, FastAPI, Pydantic, SQLAlchemy and Alembic, with PostgreSQL 17 / -PostGIS and managed original files. The installed runtime tested here -contains FastAPI 0.162.0. Package minimum Python requirements can differ -from the bundled executable; the metadata reference preserves both. No -stack rewrite is implied by the beta label. +The accepted package supports Windows x64 fresh installation and upgrade +from 1.7.2.1. Its native shell uses Rust 2021, Tauri 2 and Microsoft +WebView2; browser assets are JavaScript built with Vite 8.1.6. This +describes the native desktop frontend; Station has a separate React +operator, specified below or in its product manual. Canonical business +workflows use bundled CPython 3.13.5, FastAPI, Pydantic, SQLAlchemy and +Alembic, with PostgreSQL 17 / PostGIS and managed original files. The +installed runtime tested here contains FastAPI 0.162.0. Package minimum +Python requirements can differ from the bundled executable; the metadata +reference preserves both. No stack rewrite is implied by the beta label. The native transport is fixed to loopback 127.0.0.1:15480; PostgreSQL uses the configured local runtime port (default 15432). Optional local @@ -519,8 +532,8 @@ a full backup. Use Restore Latest Backup through the supported controls. If the result says Restore needs service start, use Start, then Check, and reopen a known record. Do not repeat restore merely because services need to -start. The fresh-profile acceptance verified that a fulfilled request -survived restore and a post-backup marker did not. +start. The Windows 1.6.0.1 Beta 1 fresh-install acceptance verified that +a fulfilled request survived restore and a post-backup marker did not. Keep Station’s dedicated database and media evidence together in its own backup. Core’s native-profile backup must not be assumed to include an @@ -549,28 +562,21 @@ Troubleshooting Verified workflows and limits +The table records selected synthetic workflows from the original Windows +1.6.0.1 Beta 1 Sandbox run. Station’s later delivery has separate +Windows 1.6.0.1 acceptance. See the Windows 1.8.0.1 acceptance summary +for the workflows and upgrade path exercised on the current MSI. + Product Recorded result Precisely exercised --------- ----------------- -------------------------------------------------------------------------------------------------------------------- Zoning PASS GeoJSON/PostGIS import, cited dimensional rule, parcel answer, staff review/history/snapshot and native workspace. -These results come from the identified signed candidate’s fresh -normal-profile Sandbox exercise: real native IPC/HTTP/PostgreSQL and -selected headless controls. All accounts, source bundles and media were -synthetic. The guest install/uninstall and recovery passed, and the -owned Sandbox stopped. No host installed application or standalone -CivicCast was changed. This documentation task reuses those receipts; it -does not claim a new software acceptance run. - -See the Windows acceptance summary for this MSI. The historical evidence -index applies to its original build. - -The limits remain: actual city field acceptance and equipment/network -commissioning; Station automatic provisioning/SCM commissioning; every -UI/role combination; field recognition accuracy; and historical in-place -upgrades are not certified. They are not five invented feature -requirements. Fresh-install controlled beta handoff remains the accepted -scope. This package makes no city-deployment, publication or -general-availability claim. +The Windows 1.8.0.1 acceptance covers the tested installation paths and +selected synthetic workflows, including Boards & Commissions, Contracts, +and Procurement. Earlier results apply to their original builds. City +field acceptance, physical equipment and network commissioning, Station +automatic provisioning, and comprehensive UI and role coverage remain +outside the 1.8.0.1 checks. Terms of service and license @@ -635,12 +641,12 @@ amounts do not become a new authoritative calculation. Beta operation and recovery -Use the identified candidate in its supported fresh-install scope. -Preserve backups and original evidence. Test physical equipment and -chosen network/service configuration before relying on them. The -supplied acceptance describes selected synthetic workflows, not every -screen, vendor, field condition or upgrade. Operators decide whether a -particular deployment meets their own operational obligations. +Windows 1.8.0.1 was tested for fresh installation and in-place upgrade +from 1.7.2.1. Upgrade paths from versions older than 1.7.2.1 are +unverified. Station uses its separately configured service. Keep backups +and original evidence. Test your physical equipment and network and +service configuration before relying on them. See the acceptance summary +for the tested paths. Warranty and liability diff --git a/docs/beta-1/docx/Townlight-Code-Manual-Beta-1.docx b/docs/beta-1/docx/Townlight-Code-Manual-Beta-1.docx index 533044f..c9d03a7 100644 Binary files a/docs/beta-1/docx/Townlight-Code-Manual-Beta-1.docx and b/docs/beta-1/docx/Townlight-Code-Manual-Beta-1.docx differ diff --git a/docs/beta-1/docx/Townlight-Core-Manual-Beta-1.docx b/docs/beta-1/docx/Townlight-Core-Manual-Beta-1.docx index 2217ed2..0d6c110 100644 Binary files a/docs/beta-1/docx/Townlight-Core-Manual-Beta-1.docx and b/docs/beta-1/docx/Townlight-Core-Manual-Beta-1.docx differ diff --git a/docs/beta-1/docx/Townlight-Inspections-Manual-Beta-1.docx b/docs/beta-1/docx/Townlight-Inspections-Manual-Beta-1.docx index 41f08b5..c1d12c9 100644 Binary files a/docs/beta-1/docx/Townlight-Inspections-Manual-Beta-1.docx and b/docs/beta-1/docx/Townlight-Inspections-Manual-Beta-1.docx differ diff --git a/docs/beta-1/docx/Townlight-Meetings-Manual-Beta-1.docx b/docs/beta-1/docx/Townlight-Meetings-Manual-Beta-1.docx index 083bd29..0eebbb9 100644 Binary files a/docs/beta-1/docx/Townlight-Meetings-Manual-Beta-1.docx and b/docs/beta-1/docx/Townlight-Meetings-Manual-Beta-1.docx differ diff --git a/docs/beta-1/docx/Townlight-Permitting-Manual-Beta-1.docx b/docs/beta-1/docx/Townlight-Permitting-Manual-Beta-1.docx index b83237e..b16b652 100644 Binary files a/docs/beta-1/docx/Townlight-Permitting-Manual-Beta-1.docx and b/docs/beta-1/docx/Townlight-Permitting-Manual-Beta-1.docx differ diff --git a/docs/beta-1/docx/Townlight-Planning-Manual-Beta-1.docx b/docs/beta-1/docx/Townlight-Planning-Manual-Beta-1.docx index b040999..50a8193 100644 Binary files a/docs/beta-1/docx/Townlight-Planning-Manual-Beta-1.docx and b/docs/beta-1/docx/Townlight-Planning-Manual-Beta-1.docx differ diff --git a/docs/beta-1/docx/Townlight-Records-Manual-Beta-1.docx b/docs/beta-1/docx/Townlight-Records-Manual-Beta-1.docx index dfdeb4a..6688ade 100644 Binary files a/docs/beta-1/docx/Townlight-Records-Manual-Beta-1.docx and b/docs/beta-1/docx/Townlight-Records-Manual-Beta-1.docx differ diff --git a/docs/beta-1/docx/Townlight-Station-Manual-Beta-1.docx b/docs/beta-1/docx/Townlight-Station-Manual-Beta-1.docx index 9ace432..99cb82a 100644 Binary files a/docs/beta-1/docx/Townlight-Station-Manual-Beta-1.docx and b/docs/beta-1/docx/Townlight-Station-Manual-Beta-1.docx differ diff --git a/docs/beta-1/docx/Townlight-Suite-Manual-Beta-1.docx b/docs/beta-1/docx/Townlight-Suite-Manual-Beta-1.docx index 3abbeee..94378e0 100644 Binary files a/docs/beta-1/docx/Townlight-Suite-Manual-Beta-1.docx and b/docs/beta-1/docx/Townlight-Suite-Manual-Beta-1.docx differ diff --git a/docs/beta-1/docx/Townlight-Zoning-Manual-Beta-1.docx b/docs/beta-1/docx/Townlight-Zoning-Manual-Beta-1.docx index 68eb999..517d4a5 100644 Binary files a/docs/beta-1/docx/Townlight-Zoning-Manual-Beta-1.docx and b/docs/beta-1/docx/Townlight-Zoning-Manual-Beta-1.docx differ diff --git a/docs/beta-1/index.html b/docs/beta-1/index.html index 4e31cc8..ad439d8 100644 --- a/docs/beta-1/index.html +++ b/docs/beta-1/index.html @@ -1 +1 @@ -Townlight | Townlight Beta 1
townlightTownlight Beta 1
The connected municipal suite · Townlight Beta 1

Municipal work with a clear record.

Connected municipal products help staff prepare, review and retain municipal work. Start with a controlled beta evaluation, keep original evidence, and make each official decision deliberately.

Read the manualPrintable manualWord manualTechnical reference
Signed Windows x64 MSI 1.8.0.1AGPL-3.0-onlyBeta evaluation · Windows fresh-install scope
The product family

The kept products and their connected workflows.

Designed around the record

Prepare, review, hand off.

Keep source versions and original hashes connected to staff work. Select the intended audience, review the saved revision, and explicitly attach the resulting evidence. Records retains the final response and release decisions.

A practical beta deployment

The selected Townlight desktop composition includes Access and Notice staff workspaces alongside the existing municipal workflows. Station is a separately configured capture and media service. Standalone CivicCast keeps its own product, installation and data.

Download the Windows x64 beta 1.8.0.1, matching source and checksums from GitHub.

Architecture

The suite and its boundaries

Townlight architecture and evidence flow

Native staff workspaces use canonical Python/PostgreSQL services. Station has a separate database, media store and explicit Townlight authority.

Evidence rather than promises

Windows Sandbox acceptance passed.

The Windows acceptance summary describes the fresh Windows install, staff workflow, and 1.7.2.1 upgrade checks. See its scope for coverage of other workflows and equipment.

Read the exact acceptance and limits →

Ready to evaluate?

Begin with the current manual and download the Windows x64 beta 1.8.0.1. Configure the chosen test site and have its staff review source applicability and run the existing workflows.

Detailed READMEVersions and provenance
Station delivery update

Live cable coverage and recorded video delivery

Station offers an encrypted live SRT feed to separate CivicCast while recording. The PEG operator controls cable broadcast. Completed recordings can be explicitly uploaded to YouTube with a reviewed title and chosen visibility. The private Records original stays intact.

Setup, staff steps and API examples

See the Townlight Portal Guide for the separately deployed resident portal.

\ No newline at end of file +Townlight | Townlight Beta 1
townlightTownlight Beta 1
The connected municipal suite · Townlight Beta 1

Municipal work with a clear record.

Connected municipal products help staff prepare, review and retain municipal work. Start with a controlled beta evaluation, keep original evidence, and make each official decision deliberately.

Read the manualPrintable manualWord manualTechnical reference
Signed Windows x64 MSI 1.8.0.1AGPL-3.0-onlyBeta evaluation · Windows fresh install and tested 1.7.2.1 upgrade
The product family

The kept products and their connected workflows.

Designed around the record

Prepare, review, hand off.

Keep source versions and original hashes connected to staff work. Select the intended audience, review the saved revision, and explicitly attach the resulting evidence. Records retains the final response and release decisions.

A practical beta deployment

The selected Townlight desktop composition includes Access and Notice staff workspaces alongside the existing municipal workflows. Station is a separately configured capture and media service. Standalone CivicCast keeps its own product, installation and data.

Download the Windows x64 beta 1.8.0.1, matching source and checksums from GitHub.

Architecture

The suite and its boundaries

Townlight architecture and evidence flow

Native staff workspaces use canonical Python/PostgreSQL services. Station has a separate database, media store and explicit Townlight authority.

Evidence rather than promises

Windows Sandbox acceptance passed.

The Windows acceptance summary describes the fresh Windows install, staff workflow, and 1.7.2.1 upgrade checks. See its scope for coverage of other workflows and equipment.

Read the exact acceptance and limits →

Ready to evaluate?

Begin with the current manual and download the Windows x64 beta 1.8.0.1. Configure the chosen test site and have its staff review source applicability and run the existing workflows.

Detailed READMEVersions and provenance
Station delivery update

Live cable coverage and recorded video delivery

Station offers an encrypted live SRT feed to separate CivicCast while recording. The PEG operator controls cable broadcast. Completed recordings can be explicitly uploaded to YouTube with a reviewed title and chosen visibility. The private Records original stays intact.

Setup, staff steps and API examples

See the Townlight Portal Guide for the separately deployed resident portal.

\ No newline at end of file diff --git a/docs/beta-1/manuals/code.html b/docs/beta-1/manuals/code.html index a8e29d3..99b2b4e 100644 --- a/docs/beta-1/manuals/code.html +++ b/docs/beta-1/manuals/code.html @@ -1,16 +1,16 @@ Townlight Code Manual | Townlight Windows Beta 1 +header .brand{display:inline-flex;align-items:center;max-width:100%;flex-shrink:0}header .brand img{display:block;width:217px;max-width:100%;height:auto} -
Townlight +
Townlight
@@ -161,13 +161,15 @@

Beta identity

Acceptance composition -Fresh Windows x64 profile; inspections-preview; Station configured -separately +Windows x64 fresh install and upgrade from 1.7.2.1. Select the full profile. Station uses separate configuration. -

Start a new installation with an empty database and fresh Windows profile. For an upgrade from Windows 1.7.2.1, keep the existing profile. The approved profile path is %LOCALAPPDATA%\CivicSuite. Keep existing profiles and backups.

+

First run

+

Upgrade from 1.7.2.1. For the tested upgrade from 1.7.2.1, back up city data and settings, close Townlight, run the signed Windows 1.8.0.1 MSI, and reopen Townlight under the same Windows account with its existing profile. Keep the existing %LOCALAPPDATA%\CivicSuite directory. Upgrade paths from versions older than 1.7.2.1 are unverified. Station uses its separately configured service.

+

Fresh installation

+

Run the signed Windows 1.8.0.1 MSI and use an empty database and a new Townlight profile for first run.

  1. Download the signed MSI, matching source companion and checksums from the public Windows release.
  2. Verify the MSI hash and Authenticode publisher before installation. See the Windows acceptance summary for the tested setup.
    3. @@ -374,8 +376,7 @@

    Operate the remain in the Code API source supplement.

    Technical specifications

    Runtime and storage

    -

    The accepted package targets Windows x64 fresh -installation. Its native shell uses Rust 2021, Tauri 2 +

    The accepted package supports Windows x64 fresh installation and upgrade from 1.7.2.1. Its native shell uses Rust 2021, Tauri 2 and Microsoft WebView2; browser assets are JavaScript built with Vite 8.1.6. This describes the native desktop frontend; Station has a separate React operator, specified below or in @@ -594,7 +595,7 @@

    Backup recovery and controls. If the result says Restore needs service start, use Start, then Check, and reopen a known record. Do not repeat restore merely because services -need to start. The fresh-profile acceptance verified that a fulfilled +need to start. The Windows 1.6.0.1 Beta 1 fresh-install acceptance verified that a fulfilled request survived restore and a post-backup marker did not.

    Keep Station’s dedicated database and media evidence together in its own backup. Core’s native-profile backup must not be assumed to include @@ -675,6 +676,7 @@

    Troubleshooting

    Verified workflows and limits

    +

    The table records selected synthetic workflows from the original Windows 1.6.0.1 Beta 1 Sandbox run. Station’s later delivery has separate Windows 1.6.0.1 acceptance. See the Windows 1.8.0.1 acceptance summary for the workflows and upgrade path exercised on the current MSI.

    @@ -698,21 +700,8 @@

    Verified workflows and

    -

    These results come from the identified signed candidate’s fresh -normal-profile Sandbox exercise: real native IPC/HTTP/PostgreSQL and -selected headless controls. All accounts, source bundles and media were -synthetic. The guest install/uninstall and recovery passed, and the -owned Sandbox stopped. No host installed application or standalone -CivicCast was changed. This documentation task reuses those receipts; it -does not claim a new software acceptance run.

    -

    See the Windows acceptance summary for this MSI. The historical evidence index applies to its original build.

    -

    The limits remain: actual city field acceptance and equipment/network -commissioning; Station automatic provisioning/SCM commissioning; every -UI/role combination; field recognition accuracy; and historical in-place -upgrades are not certified. They are not five invented feature -requirements. Fresh-install controlled beta handoff remains the accepted -scope. This package makes no city-deployment, publication or -general-availability claim.

    + +

    The Windows 1.8.0.1 acceptance covers the tested installation paths and selected synthetic workflows, including Boards & Commissions, Contracts, and Procurement. Earlier results apply to their original builds. City field acceptance, physical equipment and network commissioning, Station automatic provisioning, and comprehensive UI and role coverage remain outside the 1.8.0.1 checks.

    Terms of service and license

    Scope and status

    These terms describe the Townlight Beta 1 software and this @@ -769,12 +758,7 @@

    Staff decisions and authority remains with the adopted source and responsible organization; imported amounts do not become a new authoritative calculation.

    Beta operation and recovery

    -

    Use the identified candidate in its supported fresh-install scope. -Preserve backups and original evidence. Test physical equipment and -chosen network/service configuration before relying on them. The -supplied acceptance describes selected synthetic workflows, not every -screen, vendor, field condition or upgrade. Operators decide whether a -particular deployment meets their own operational obligations.

    +

    Windows 1.8.0.1 was tested for fresh installation and in-place upgrade from 1.7.2.1. Upgrade paths from versions older than 1.7.2.1 are unverified. Station uses its separately configured service. Keep backups and original evidence. Test your physical equipment and network and service configuration before relying on them. See the acceptance summary for the tested paths.

    Warranty and liability

    The covered software’s warranty and liability conditions are those in sections 15–17 of the supplied AGPL and any applicable separate written @@ -980,4 +964,4 @@

    Workflow subject index

  3. Full AGPL text

    4. -
    Townlight · AGPL-3.0-only · Candidate evidence applies only to its identified artifacts.
    \ No newline at end of file + \ No newline at end of file diff --git a/docs/beta-1/manuals/core.html b/docs/beta-1/manuals/core.html index fb6a378..d3ddae8 100644 --- a/docs/beta-1/manuals/core.html +++ b/docs/beta-1/manuals/core.html @@ -1,16 +1,16 @@ Townlight Core Manual | Townlight Windows Beta 1 +header .brand{display:inline-flex;align-items:center;max-width:100%;flex-shrink:0}header .brand img{display:block;width:217px;max-width:100%;height:auto} -
    Townlight +
    Townlight
    @@ -161,13 +161,15 @@

    Beta identity

    Acceptance composition -Fresh Windows x64 profile; inspections-preview; Station configured -separately +Windows x64 fresh install and upgrade from 1.7.2.1. Select the full profile. Station uses separate configuration. -

    Start a new installation with an empty database and fresh Windows profile. For an upgrade from Windows 1.7.2.1, keep the existing profile. The approved profile path is %LOCALAPPDATA%\CivicSuite. Keep existing profiles and backups.

    +

    First run

    +

    Upgrade from 1.7.2.1. For the tested upgrade from 1.7.2.1, back up city data and settings, close Townlight, run the signed Windows 1.8.0.1 MSI, and reopen Townlight under the same Windows account with its existing profile. Keep the existing %LOCALAPPDATA%\CivicSuite directory. Upgrade paths from versions older than 1.7.2.1 are unverified. Station uses its separately configured service.

    +

    Fresh installation

    +

    Run the signed Windows 1.8.0.1 MSI and use an empty database and a new Townlight profile for first run.

    1. Download the signed MSI, matching source companion and checksums from the public Windows release.
    2. Verify the MSI hash and Authenticode publisher before installation. See the Windows acceptance summary for the tested setup.
      3. @@ -413,8 +415,7 @@

      Scaffold plan and generate

      and the Records catalog facade.

      Technical specifications

      Runtime and storage

      -

      The accepted package targets Windows x64 fresh -installation. Its native shell uses Rust 2021, Tauri 2 +

      The accepted package supports Windows x64 fresh installation and upgrade from 1.7.2.1. Its native shell uses Rust 2021, Tauri 2 and Microsoft WebView2; browser assets are JavaScript built with Vite 8.1.6. This describes the native desktop frontend; Station has a separate React operator, specified below or in @@ -618,7 +619,7 @@

      Backup recovery and controls. If the result says Restore needs service start, use Start, then Check, and reopen a known record. Do not repeat restore merely because services -need to start. The fresh-profile acceptance verified that a fulfilled +need to start. The Windows 1.6.0.1 Beta 1 fresh-install acceptance verified that a fulfilled request survived restore and a post-backup marker did not.

      Keep Station’s dedicated database and media evidence together in its own backup. Core’s native-profile backup must not be assumed to include @@ -699,6 +700,7 @@

      Troubleshooting

      Verified workflows and limits

      +

      The table records selected synthetic workflows from the original Windows 1.6.0.1 Beta 1 Sandbox run. Station’s later delivery has separate Windows 1.6.0.1 acceptance. See the Windows 1.8.0.1 acceptance summary for the workflows and upgrade path exercised on the current MSI.

      @@ -722,21 +724,8 @@

      Verified workflows and

      -

      These results come from the identified signed candidate’s fresh -normal-profile Sandbox exercise: real native IPC/HTTP/PostgreSQL and -selected headless controls. All accounts, source bundles and media were -synthetic. The guest install/uninstall and recovery passed, and the -owned Sandbox stopped. No host installed application or standalone -CivicCast was changed. This documentation task reuses those receipts; it -does not claim a new software acceptance run.

      -

      See the Windows acceptance summary for this MSI. The historical evidence index applies to its original build.

      -

      The limits remain: actual city field acceptance and equipment/network -commissioning; Station automatic provisioning/SCM commissioning; every -UI/role combination; field recognition accuracy; and historical in-place -upgrades are not certified. They are not five invented feature -requirements. Fresh-install controlled beta handoff remains the accepted -scope. This package makes no city-deployment, publication or -general-availability claim.

      + +

      The Windows 1.8.0.1 acceptance covers the tested installation paths and selected synthetic workflows, including Boards & Commissions, Contracts, and Procurement. Earlier results apply to their original builds. City field acceptance, physical equipment and network commissioning, Station automatic provisioning, and comprehensive UI and role coverage remain outside the 1.8.0.1 checks.

      Terms of service and license

      Scope and status

      These terms describe the Townlight Beta 1 software and this @@ -793,12 +782,7 @@

      Staff decisions and authority remains with the adopted source and responsible organization; imported amounts do not become a new authoritative calculation.

      Beta operation and recovery

      -

      Use the identified candidate in its supported fresh-install scope. -Preserve backups and original evidence. Test physical equipment and -chosen network/service configuration before relying on them. The -supplied acceptance describes selected synthetic workflows, not every -screen, vendor, field condition or upgrade. Operators decide whether a -particular deployment meets their own operational obligations.

      +

      Windows 1.8.0.1 was tested for fresh installation and in-place upgrade from 1.7.2.1. Upgrade paths from versions older than 1.7.2.1 are unverified. Station uses its separately configured service. Keep backups and original evidence. Test your physical equipment and network and service configuration before relying on them. See the acceptance summary for the tested paths.

      Warranty and liability

      The covered software’s warranty and liability conditions are those in sections 15–17 of the supplied AGPL and any applicable separate written @@ -1003,4 +987,4 @@

      Workflow subject index

    3. Full AGPL text

      4. -
      Townlight · AGPL-3.0-only · Candidate evidence applies only to its identified artifacts.
      \ No newline at end of file + \ No newline at end of file diff --git a/docs/beta-1/manuals/inspections.html b/docs/beta-1/manuals/inspections.html index 2c560cf..e2f77e1 100644 --- a/docs/beta-1/manuals/inspections.html +++ b/docs/beta-1/manuals/inspections.html @@ -1,16 +1,16 @@ Townlight Inspections Manual | Townlight Windows Beta 1 +header .brand{display:inline-flex;align-items:center;max-width:100%;flex-shrink:0}header .brand img{display:block;width:217px;max-width:100%;height:auto} -
      Townlight +
      Townlight
      @@ -161,13 +161,15 @@

      Beta identity

      Acceptance composition -Fresh Windows x64 profile; inspections-preview; Station configured -separately +Windows x64 fresh install and upgrade from 1.7.2.1. Select the full profile. Station uses separate configuration. -

      Start a new installation with an empty database and fresh Windows profile. For an upgrade from Windows 1.7.2.1, keep the existing profile. The approved profile path is %LOCALAPPDATA%\CivicSuite. Keep existing profiles and backups.

      +

      First run

      +

      Upgrade from 1.7.2.1. For the tested upgrade from 1.7.2.1, back up city data and settings, close Townlight, run the signed Windows 1.8.0.1 MSI, and reopen Townlight under the same Windows account with its existing profile. Keep the existing %LOCALAPPDATA%\CivicSuite directory. Upgrade paths from versions older than 1.7.2.1 are unverified. Station uses its separately configured service.

      +

      Fresh installation

      +

      Run the signed Windows 1.8.0.1 MSI and use an empty database and a new Townlight profile for first run.

      1. Download the signed MSI, matching source companion and checksums from the public Windows release.
      2. Verify the MSI hash and Authenticode publisher before installation. See the Windows acceptance summary for the tested setup.
        3. @@ -401,8 +403,7 @@

        Prepare an outline for models and townlight_runtime/inspections_bridge.py.

        Technical specifications

        Runtime and storage

        -

        The accepted package targets Windows x64 fresh -installation. Its native shell uses Rust 2021, Tauri 2 +

        The accepted package supports Windows x64 fresh installation and upgrade from 1.7.2.1. Its native shell uses Rust 2021, Tauri 2 and Microsoft WebView2; browser assets are JavaScript built with Vite 8.1.6. This describes the native desktop frontend; Station has a separate React operator, specified below or in @@ -625,7 +626,7 @@

        Backup recovery and controls. If the result says Restore needs service start, use Start, then Check, and reopen a known record. Do not repeat restore merely because services -need to start. The fresh-profile acceptance verified that a fulfilled +need to start. The Windows 1.6.0.1 Beta 1 fresh-install acceptance verified that a fulfilled request survived restore and a post-backup marker did not.

        Keep Station’s dedicated database and media evidence together in its own backup. Core’s native-profile backup must not be assumed to include @@ -718,6 +719,7 @@

        Troubleshooting

        Verified workflows and limits

        +

        The table records selected synthetic workflows from the original Windows 1.6.0.1 Beta 1 Sandbox run. Station’s later delivery has separate Windows 1.6.0.1 acceptance. See the Windows 1.8.0.1 acceptance summary for the workflows and upgrade path exercised on the current MSI.

        @@ -741,21 +743,8 @@

        Verified workflows and

        -

        These results come from the identified signed candidate’s fresh -normal-profile Sandbox exercise: real native IPC/HTTP/PostgreSQL and -selected headless controls. All accounts, source bundles and media were -synthetic. The guest install/uninstall and recovery passed, and the -owned Sandbox stopped. No host installed application or standalone -CivicCast was changed. This documentation task reuses those receipts; it -does not claim a new software acceptance run.

        -

        See the Windows acceptance summary for this MSI. The historical evidence index applies to its original build.

        -

        The limits remain: actual city field acceptance and equipment/network -commissioning; Station automatic provisioning/SCM commissioning; every -UI/role combination; field recognition accuracy; and historical in-place -upgrades are not certified. They are not five invented feature -requirements. Fresh-install controlled beta handoff remains the accepted -scope. This package makes no city-deployment, publication or -general-availability claim.

        + +

        The Windows 1.8.0.1 acceptance covers the tested installation paths and selected synthetic workflows, including Boards & Commissions, Contracts, and Procurement. Earlier results apply to their original builds. City field acceptance, physical equipment and network commissioning, Station automatic provisioning, and comprehensive UI and role coverage remain outside the 1.8.0.1 checks.

        Terms of service and license

        Scope and status

        These terms describe the Townlight Beta 1 software and this @@ -812,12 +801,7 @@

        Staff decisions and authority remains with the adopted source and responsible organization; imported amounts do not become a new authoritative calculation.

        Beta operation and recovery

        -

        Use the identified candidate in its supported fresh-install scope. -Preserve backups and original evidence. Test physical equipment and -chosen network/service configuration before relying on them. The -supplied acceptance describes selected synthetic workflows, not every -screen, vendor, field condition or upgrade. Operators decide whether a -particular deployment meets their own operational obligations.

        +

        Windows 1.8.0.1 was tested for fresh installation and in-place upgrade from 1.7.2.1. Upgrade paths from versions older than 1.7.2.1 are unverified. Station uses its separately configured service. Keep backups and original evidence. Test your physical equipment and network and service configuration before relying on them. See the acceptance summary for the tested paths.

        Warranty and liability

        The covered software’s warranty and liability conditions are those in sections 15–17 of the supplied AGPL and any applicable separate written @@ -1023,4 +1007,4 @@

        Workflow subject index

      3. Full AGPL text

        4. -
        Townlight · AGPL-3.0-only · Candidate evidence applies only to its identified artifacts.
        \ No newline at end of file + \ No newline at end of file diff --git a/docs/beta-1/manuals/meetings.html b/docs/beta-1/manuals/meetings.html index 215b82f..6f0c98e 100644 --- a/docs/beta-1/manuals/meetings.html +++ b/docs/beta-1/manuals/meetings.html @@ -1,16 +1,16 @@ Townlight Meetings Manual | Townlight Windows Beta 1 +header .brand{display:inline-flex;align-items:center;max-width:100%;flex-shrink:0}header .brand img{display:block;width:217px;max-width:100%;height:auto} -
        Townlight +
        Townlight
        @@ -165,13 +165,15 @@

        Beta identity

        Supported acceptance profile -Windows x64 fresh install; inspections-preview; separate Station -configuration +Windows x64 fresh install and upgrade from 1.7.2.1. Select the full profile. Station uses separate configuration. -

        Windows MSI 1.8.0.1 includes Townlight Meetings 1.0.5. Use a fresh profile and empty database. The approved profile path is %LOCALAPPDATA%\CivicSuite. Preserve existing profiles, data and backups.

        +

        Windows MSI 1.8.0.1 includes Townlight Meetings 1.0.5. The approved profile path is %LOCALAPPDATA%\CivicSuite. Preserve existing profiles, data and backups.

        First run

        +

        Upgrade from 1.7.2.1. For the tested upgrade from 1.7.2.1, back up city data and settings, close Townlight, run the signed Windows 1.8.0.1 MSI, and reopen Townlight under the same Windows account with its existing profile. Keep the existing %LOCALAPPDATA%\CivicSuite directory. Upgrade paths from versions older than 1.7.2.1 are unverified. Station uses its separately configured service.

        +

        Fresh installation

        +

        Run the signed Windows 1.8.0.1 MSI and use an empty database and a new Townlight profile for first run.

        1. Download the signed MSI, matching source companion and checksums from the public Windows release.
        2. Verify the MSI hash and Authenticode publisher before installation. See the Windows acceptance summary for the tested setup.
          3. @@ -358,8 +360,7 @@

          Retain action items source inventory/API companion.

          Technical specifications

          Runtime and storage

          -

          The accepted package targets Windows x64 fresh -installation. Its native shell uses Rust 2021, Tauri 2 +

          The accepted package supports Windows x64 fresh installation and upgrade from 1.7.2.1. Its native shell uses Rust 2021, Tauri 2 and Microsoft WebView2; browser assets are JavaScript built with Vite 8.1.6. This describes the native desktop frontend; Station has a separate React operator, specified below or in @@ -563,7 +564,7 @@

          Backup recovery and controls. If the result says Restore needs service start, use Start, then Check, and reopen a known record. Do not repeat restore merely because services -need to start. The fresh-profile acceptance verified that a fulfilled +need to start. The Windows 1.6.0.1 Beta 1 fresh-install acceptance verified that a fulfilled request survived restore and a post-backup marker did not.

          Keep Station’s dedicated database and media evidence together in its own backup. Core’s native-profile backup must not be assumed to include @@ -644,6 +645,7 @@

          Troubleshooting

          Verified workflows and limits

          +

          The table records selected synthetic workflows from the original Windows 1.6.0.1 Beta 1 Sandbox run. Station’s later delivery has separate Windows 1.6.0.1 acceptance. See the Windows 1.8.0.1 acceptance summary for the workflows and upgrade path exercised on the current MSI.

          @@ -667,21 +669,8 @@

          Verified workflows and

          -

          These results come from the identified signed candidate’s fresh -normal-profile Sandbox exercise: real native IPC/HTTP/PostgreSQL and -selected headless controls. All accounts, source bundles and media were -synthetic. The guest install/uninstall and recovery passed, and the -owned Sandbox stopped. No host installed application or standalone -CivicCast was changed. This documentation task reuses those receipts; it -does not claim a new software acceptance run.

          -

          See the Windows acceptance summary for this MSI. The historical evidence index applies to its original build.

          -

          The limits remain: actual city field acceptance and equipment/network -commissioning; Station automatic provisioning/SCM commissioning; every -UI/role combination; field recognition accuracy; and historical in-place -upgrades are not certified. They are not five invented feature -requirements. Fresh-install controlled beta handoff remains the accepted -scope. This package makes no city-deployment, publication or -general-availability claim.

          + +

          The Windows 1.8.0.1 acceptance covers the tested installation paths and selected synthetic workflows, including Boards & Commissions, Contracts, and Procurement. Earlier results apply to their original builds. City field acceptance, physical equipment and network commissioning, Station automatic provisioning, and comprehensive UI and role coverage remain outside the 1.8.0.1 checks.

          Terms of service and license

          Scope and status

          These terms describe the Townlight Beta 1 software and this @@ -738,12 +727,7 @@

          Staff decisions and authority remains with the adopted source and responsible organization; imported amounts do not become a new authoritative calculation.

          Beta operation and recovery

          -

          Use the identified candidate in its supported fresh-install scope. -Preserve backups and original evidence. Test physical equipment and -chosen network/service configuration before relying on them. The -supplied acceptance describes selected synthetic workflows, not every -screen, vendor, field condition or upgrade. Operators decide whether a -particular deployment meets their own operational obligations.

          +

          Windows 1.8.0.1 was tested for fresh installation and in-place upgrade from 1.7.2.1. Upgrade paths from versions older than 1.7.2.1 are unverified. Station uses its separately configured service. Keep backups and original evidence. Test your physical equipment and network and service configuration before relying on them. See the acceptance summary for the tested paths.

          Warranty and liability

          The covered software’s warranty and liability conditions are those in sections 15–17 of the supplied AGPL and any applicable separate written @@ -946,4 +930,4 @@

          Workflow subject index

        3. Full AGPL text

          4. -

          The resident portal is deployed separately. See the Townlight Portal Guide for its workflow and acceptance limits.

          Townlight · AGPL-3.0-only · Candidate evidence applies only to its identified artifacts.
          \ No newline at end of file +

          The resident portal is deployed separately. See the Townlight Portal Guide for its workflow and acceptance limits.

          \ No newline at end of file diff --git a/docs/beta-1/manuals/permitting.html b/docs/beta-1/manuals/permitting.html index 090e9ae..5f60197 100644 --- a/docs/beta-1/manuals/permitting.html +++ b/docs/beta-1/manuals/permitting.html @@ -1,16 +1,16 @@ Townlight Permitting Manual | Townlight Windows Beta 1 +header .brand{display:inline-flex;align-items:center;max-width:100%;flex-shrink:0}header .brand img{display:block;width:217px;max-width:100%;height:auto} -
          Townlight +
          Townlight
          @@ -162,13 +162,15 @@

          Beta identity

          Acceptance composition -Fresh Windows x64 profile; inspections-preview; Station configured -separately +Windows x64 fresh install and upgrade from 1.7.2.1. Select the full profile. Station uses separate configuration. -

          Start a new installation with an empty database and fresh Windows profile. For an upgrade from Windows 1.7.2.1, keep the existing profile. The approved profile path is %LOCALAPPDATA%\CivicSuite. Keep existing profiles and backups.

          +

          First run

          +

          Upgrade from 1.7.2.1. For the tested upgrade from 1.7.2.1, back up city data and settings, close Townlight, run the signed Windows 1.8.0.1 MSI, and reopen Townlight under the same Windows account with its existing profile. Keep the existing %LOCALAPPDATA%\CivicSuite directory. Upgrade paths from versions older than 1.7.2.1 are unverified. Station uses its separately configured service.

          +

          Fresh installation

          +

          Run the signed Windows 1.8.0.1 MSI and use an empty database and a new Townlight profile for first run.

          1. Download the signed MSI, matching source companion and checksums from the public Windows release.
          2. Verify the MSI hash and Authenticode publisher before installation. See the Windows acceptance summary for the tested setup.
            3. @@ -351,8 +353,7 @@

            Describe a view.

            Technical specifications

            Runtime and storage

            -

            The accepted package targets Windows x64 fresh -installation. Its native shell uses Rust 2021, Tauri 2 +

            The accepted package supports Windows x64 fresh installation and upgrade from 1.7.2.1. Its native shell uses Rust 2021, Tauri 2 and Microsoft WebView2; browser assets are JavaScript built with Vite 8.1.6. This describes the native desktop frontend; Station has a separate React operator, specified below or in @@ -579,7 +580,7 @@

            Backup recovery and controls. If the result says Restore needs service start, use Start, then Check, and reopen a known record. Do not repeat restore merely because services -need to start. The fresh-profile acceptance verified that a fulfilled +need to start. The Windows 1.6.0.1 Beta 1 fresh-install acceptance verified that a fulfilled request survived restore and a post-backup marker did not.

            Keep Station’s dedicated database and media evidence together in its own backup. Core’s native-profile backup must not be assumed to include @@ -660,6 +661,7 @@

            Troubleshooting

            Verified workflows and limits

            +

            The table records selected synthetic workflows from the original Windows 1.6.0.1 Beta 1 Sandbox run. Station’s later delivery has separate Windows 1.6.0.1 acceptance. See the Windows 1.8.0.1 acceptance summary for the workflows and upgrade path exercised on the current MSI.

            @@ -684,21 +686,8 @@

            Verified workflows and

            -

            These results come from the identified signed candidate’s fresh -normal-profile Sandbox exercise: real native IPC/HTTP/PostgreSQL and -selected headless controls. All accounts, source bundles and media were -synthetic. The guest install/uninstall and recovery passed, and the -owned Sandbox stopped. No host installed application or standalone -CivicCast was changed. This documentation task reuses those receipts; it -does not claim a new software acceptance run.

            -

            See the Windows acceptance summary for this MSI. The historical evidence index applies to its original build.

            -

            The limits remain: actual city field acceptance and equipment/network -commissioning; Station automatic provisioning/SCM commissioning; every -UI/role combination; field recognition accuracy; and historical in-place -upgrades are not certified. They are not five invented feature -requirements. Fresh-install controlled beta handoff remains the accepted -scope. This package makes no city-deployment, publication or -general-availability claim.

            + +

            The Windows 1.8.0.1 acceptance covers the tested installation paths and selected synthetic workflows, including Boards & Commissions, Contracts, and Procurement. Earlier results apply to their original builds. City field acceptance, physical equipment and network commissioning, Station automatic provisioning, and comprehensive UI and role coverage remain outside the 1.8.0.1 checks.

            Terms of service and license

            Scope and status

            These terms describe the Townlight Beta 1 software and this @@ -755,12 +744,7 @@

            Staff decisions and authority remains with the adopted source and responsible organization; imported amounts do not become a new authoritative calculation.

            Beta operation and recovery

            -

            Use the identified candidate in its supported fresh-install scope. -Preserve backups and original evidence. Test physical equipment and -chosen network/service configuration before relying on them. The -supplied acceptance describes selected synthetic workflows, not every -screen, vendor, field condition or upgrade. Operators decide whether a -particular deployment meets their own operational obligations.

            +

            Windows 1.8.0.1 was tested for fresh installation and in-place upgrade from 1.7.2.1. Upgrade paths from versions older than 1.7.2.1 are unverified. Station uses its separately configured service. Keep backups and original evidence. Test your physical equipment and network and service configuration before relying on them. See the acceptance summary for the tested paths.

            Warranty and liability

            The covered software’s warranty and liability conditions are those in sections 15–17 of the supplied AGPL and any applicable separate written @@ -958,4 +942,4 @@

            Workflow subject index

          3. Full AGPL text

            4. -
            Townlight · AGPL-3.0-only · Candidate evidence applies only to its identified artifacts.
            \ No newline at end of file + \ No newline at end of file diff --git a/docs/beta-1/manuals/planning.html b/docs/beta-1/manuals/planning.html index 22ef177..b4617d5 100644 --- a/docs/beta-1/manuals/planning.html +++ b/docs/beta-1/manuals/planning.html @@ -1,16 +1,16 @@ Townlight Planning Manual | Townlight Windows Beta 1 +header .brand{display:inline-flex;align-items:center;max-width:100%;flex-shrink:0}header .brand img{display:block;width:217px;max-width:100%;height:auto} -
            Townlight +
            Townlight
            @@ -161,13 +161,15 @@

            Beta identity

            Acceptance composition -Fresh Windows x64 profile; inspections-preview; Station configured -separately +Windows x64 fresh install and upgrade from 1.7.2.1. Select the full profile. Station uses separate configuration. -

            Start a new installation with an empty database and fresh Windows profile. For an upgrade from Windows 1.7.2.1, keep the existing profile. The approved profile path is %LOCALAPPDATA%\CivicSuite. Keep existing profiles and backups.

            +

            First run

            +

            Upgrade from 1.7.2.1. For the tested upgrade from 1.7.2.1, back up city data and settings, close Townlight, run the signed Windows 1.8.0.1 MSI, and reopen Townlight under the same Windows account with its existing profile. Keep the existing %LOCALAPPDATA%\CivicSuite directory. Upgrade paths from versions older than 1.7.2.1 are unverified. Station uses its separately configured service.

            +

            Fresh installation

            +

            Run the signed Windows 1.8.0.1 MSI and use an empty database and a new Townlight profile for first run.

            1. Download the signed MSI, matching source companion and checksums from the public Windows release.
            2. Verify the MSI hash and Authenticode publisher before installation. See the Windows acceptance summary for the tested setup.
              3. @@ -382,8 +384,7 @@

              Retain an amendment field validation.

              Technical specifications

              Runtime and storage

              -

              The accepted package targets Windows x64 fresh -installation. Its native shell uses Rust 2021, Tauri 2 +

              The accepted package supports Windows x64 fresh installation and upgrade from 1.7.2.1. Its native shell uses Rust 2021, Tauri 2 and Microsoft WebView2; browser assets are JavaScript built with Vite 8.1.6. This describes the native desktop frontend; Station has a separate React operator, specified below or in @@ -603,7 +604,7 @@

              Backup recovery and controls. If the result says Restore needs service start, use Start, then Check, and reopen a known record. Do not repeat restore merely because services -need to start. The fresh-profile acceptance verified that a fulfilled +need to start. The Windows 1.6.0.1 Beta 1 fresh-install acceptance verified that a fulfilled request survived restore and a post-backup marker did not.

              Keep Station’s dedicated database and media evidence together in its own backup. Core’s native-profile backup must not be assumed to include @@ -684,6 +685,7 @@

              Troubleshooting

              Verified workflows and limits

              +

              The table records selected synthetic workflows from the original Windows 1.6.0.1 Beta 1 Sandbox run. Station’s later delivery has separate Windows 1.6.0.1 acceptance. See the Windows 1.8.0.1 acceptance summary for the workflows and upgrade path exercised on the current MSI.

              @@ -707,21 +709,8 @@

              Verified workflows and

              -

              These results come from the identified signed candidate’s fresh -normal-profile Sandbox exercise: real native IPC/HTTP/PostgreSQL and -selected headless controls. All accounts, source bundles and media were -synthetic. The guest install/uninstall and recovery passed, and the -owned Sandbox stopped. No host installed application or standalone -CivicCast was changed. This documentation task reuses those receipts; it -does not claim a new software acceptance run.

              -

              See the Windows acceptance summary for this MSI. The historical evidence index applies to its original build.

              -

              The limits remain: actual city field acceptance and equipment/network -commissioning; Station automatic provisioning/SCM commissioning; every -UI/role combination; field recognition accuracy; and historical in-place -upgrades are not certified. They are not five invented feature -requirements. Fresh-install controlled beta handoff remains the accepted -scope. This package makes no city-deployment, publication or -general-availability claim.

              + +

              The Windows 1.8.0.1 acceptance covers the tested installation paths and selected synthetic workflows, including Boards & Commissions, Contracts, and Procurement. Earlier results apply to their original builds. City field acceptance, physical equipment and network commissioning, Station automatic provisioning, and comprehensive UI and role coverage remain outside the 1.8.0.1 checks.

              Terms of service and license

              Scope and status

              These terms describe the Townlight Beta 1 software and this @@ -778,12 +767,7 @@

              Staff decisions and authority remains with the adopted source and responsible organization; imported amounts do not become a new authoritative calculation.

              Beta operation and recovery

              -

              Use the identified candidate in its supported fresh-install scope. -Preserve backups and original evidence. Test physical equipment and -chosen network/service configuration before relying on them. The -supplied acceptance describes selected synthetic workflows, not every -screen, vendor, field condition or upgrade. Operators decide whether a -particular deployment meets their own operational obligations.

              +

              Windows 1.8.0.1 was tested for fresh installation and in-place upgrade from 1.7.2.1. Upgrade paths from versions older than 1.7.2.1 are unverified. Station uses its separately configured service. Keep backups and original evidence. Test your physical equipment and network and service configuration before relying on them. See the acceptance summary for the tested paths.

              Warranty and liability

              The covered software’s warranty and liability conditions are those in sections 15–17 of the supplied AGPL and any applicable separate written @@ -990,4 +974,4 @@

              Workflow subject index

            3. Full AGPL text

              4. -
              Townlight · AGPL-3.0-only · Candidate evidence applies only to its identified artifacts.
              \ No newline at end of file + \ No newline at end of file diff --git a/docs/beta-1/manuals/records.html b/docs/beta-1/manuals/records.html index 527aed1..ecfece6 100644 --- a/docs/beta-1/manuals/records.html +++ b/docs/beta-1/manuals/records.html @@ -1,16 +1,16 @@ Townlight Records Manual | Townlight Windows Beta 1 +header .brand{display:inline-flex;align-items:center;max-width:100%;flex-shrink:0}header .brand img{display:block;width:217px;max-width:100%;height:auto} -
              Townlight +
              Townlight
              @@ -161,13 +161,15 @@

              Beta identity

              Acceptance composition -Fresh Windows x64 profile; inspections-preview; Station configured -separately +Windows x64 fresh install and upgrade from 1.7.2.1. Select the full profile. Station uses separate configuration. -

              Start a new installation with an empty database and fresh Windows profile. For an upgrade from Windows 1.7.2.1, keep the existing profile. The approved profile path is %LOCALAPPDATA%\CivicSuite. Keep existing profiles and backups.

              +

              First run

              +

              Upgrade from 1.7.2.1. For the tested upgrade from 1.7.2.1, back up city data and settings, close Townlight, run the signed Windows 1.8.0.1 MSI, and reopen Townlight under the same Windows account with its existing profile. Keep the existing %LOCALAPPDATA%\CivicSuite directory. Upgrade paths from versions older than 1.7.2.1 are unverified. Station uses its separately configured service.

              +

              Fresh installation

              +

              Run the signed Windows 1.8.0.1 MSI and use an empty database and a new Townlight profile for first run.

              1. Download the signed MSI, matching source companion and checksums from the public Windows release.
              2. Verify the MSI hash and Authenticode publisher before installation. See the Windows acceptance summary for the tested setup.
                3. @@ -400,8 +402,7 @@

                Exercise reference.

                Technical specifications

                Runtime and storage

                -

                The accepted package targets Windows x64 fresh -installation. Its native shell uses Rust 2021, Tauri 2 +

                The accepted package supports Windows x64 fresh installation and upgrade from 1.7.2.1. Its native shell uses Rust 2021, Tauri 2 and Microsoft WebView2; browser assets are JavaScript built with Vite 8.1.6. This describes the native desktop frontend; Station has a separate React operator, specified below or in @@ -615,7 +616,7 @@

                Backup recovery and controls. If the result says Restore needs service start, use Start, then Check, and reopen a known record. Do not repeat restore merely because services -need to start. The fresh-profile acceptance verified that a fulfilled +need to start. The Windows 1.6.0.1 Beta 1 fresh-install acceptance verified that a fulfilled request survived restore and a post-backup marker did not.

                Keep Station’s dedicated database and media evidence together in its own backup. Core’s native-profile backup must not be assumed to include @@ -696,6 +697,7 @@

                Troubleshooting

                Verified workflows and limits

                +

                The table records selected synthetic workflows from the original Windows 1.6.0.1 Beta 1 Sandbox run. Station’s later delivery has separate Windows 1.6.0.1 acceptance. See the Windows 1.8.0.1 acceptance summary for the workflows and upgrade path exercised on the current MSI.

                @@ -719,21 +721,8 @@

                Verified workflows and

                -

                These results come from the identified signed candidate’s fresh -normal-profile Sandbox exercise: real native IPC/HTTP/PostgreSQL and -selected headless controls. All accounts, source bundles and media were -synthetic. The guest install/uninstall and recovery passed, and the -owned Sandbox stopped. No host installed application or standalone -CivicCast was changed. This documentation task reuses those receipts; it -does not claim a new software acceptance run.

                -

                See the Windows acceptance summary for this MSI. The historical evidence index applies to its original build.

                -

                The limits remain: actual city field acceptance and equipment/network -commissioning; Station automatic provisioning/SCM commissioning; every -UI/role combination; field recognition accuracy; and historical in-place -upgrades are not certified. They are not five invented feature -requirements. Fresh-install controlled beta handoff remains the accepted -scope. This package makes no city-deployment, publication or -general-availability claim.

                + +

                The Windows 1.8.0.1 acceptance covers the tested installation paths and selected synthetic workflows, including Boards & Commissions, Contracts, and Procurement. Earlier results apply to their original builds. City field acceptance, physical equipment and network commissioning, Station automatic provisioning, and comprehensive UI and role coverage remain outside the 1.8.0.1 checks.

                Terms of service and license

                Scope and status

                These terms describe the Townlight Beta 1 software and this @@ -790,12 +779,7 @@

                Staff decisions and authority remains with the adopted source and responsible organization; imported amounts do not become a new authoritative calculation.

                Beta operation and recovery

                -

                Use the identified candidate in its supported fresh-install scope. -Preserve backups and original evidence. Test physical equipment and -chosen network/service configuration before relying on them. The -supplied acceptance describes selected synthetic workflows, not every -screen, vendor, field condition or upgrade. Operators decide whether a -particular deployment meets their own operational obligations.

                +

                Windows 1.8.0.1 was tested for fresh installation and in-place upgrade from 1.7.2.1. Upgrade paths from versions older than 1.7.2.1 are unverified. Station uses its separately configured service. Keep backups and original evidence. Test your physical equipment and network and service configuration before relying on them. See the acceptance summary for the tested paths.

                Warranty and liability

                The covered software’s warranty and liability conditions are those in sections 15–17 of the supplied AGPL and any applicable separate written @@ -1004,4 +988,4 @@

                Workflow subject index

              3. Full AGPL text

                4. -

                The resident portal is deployed separately. See the Townlight Portal Guide for its workflow and acceptance limits.

                Townlight · AGPL-3.0-only · Candidate evidence applies only to its identified artifacts.
                \ No newline at end of file +

                The resident portal is deployed separately. See the Townlight Portal Guide for its workflow and acceptance limits.

                \ No newline at end of file diff --git a/docs/beta-1/manuals/station.html b/docs/beta-1/manuals/station.html index ff15990..00bbb6f 100644 --- a/docs/beta-1/manuals/station.html +++ b/docs/beta-1/manuals/station.html @@ -1,16 +1,16 @@ Townlight Station Manual | Townlight Windows Beta 1 +header .brand{display:inline-flex;align-items:center;max-width:100%;flex-shrink:0}header .brand img{display:block;width:217px;max-width:100%;height:auto} -
                Townlight +
                Townlight
                @@ -126,8 +126,7 @@

                Beta identity

                Acceptance composition -Fresh Windows x64; inspections-preview; Station configured -separately +Windows x64 fresh install and upgrade from 1.7.2.1. Select the full profile. Station uses separate configuration. Candidate hashes/signature @@ -139,13 +138,11 @@

                Beta identity

                -

                This edition updates the paired-runtime instructions for the naming -candidate. It does not rename historical Station artifacts or claim new -Station software features. Use an empty database and fresh profile; no -in-place legacy upgrade or old import shim is supported. Preserve -existing city data and the prior release. The approved profile path -remains %LOCALAPPDATA%\CivicSuite for that path only.

                +

                Station continues to use its separately configured service. The Windows MSI upgrade below applies to the desktop suite.

                First run

                +

                Upgrade from 1.7.2.1. For the tested upgrade from 1.7.2.1, back up city data and settings, close Townlight, run the signed Windows 1.8.0.1 MSI, and reopen Townlight under the same Windows account with its existing profile. Keep the existing %LOCALAPPDATA%\CivicSuite directory. Upgrade paths from versions older than 1.7.2.1 are unverified. Station uses its separately configured service.

                +

                Fresh installation

                +

                Run the signed Windows 1.8.0.1 MSI and use an empty database and a new Townlight profile for first run.

                1. Download the signed MSI, matching source companion and checksums from the public Windows release.
                2. Verify the MSI hash and Authenticode publisher before installation. See the Windows acceptance summary for the tested setup.
                  3. @@ -410,8 +407,7 @@

                  Recover without service schema.

                  Technical specifications

                  Runtime and storage

                  -

                  The accepted package targets Windows x64 fresh -installation. Its native shell uses Rust 2021, Tauri 2 +

                  The accepted package supports Windows x64 fresh installation and upgrade from 1.7.2.1. Its native shell uses Rust 2021, Tauri 2 and Microsoft WebView2; browser assets are JavaScript built with Vite 8.1.6. This describes the native desktop frontend; Station has a separate React operator, specified below or in @@ -1015,20 +1011,8 @@

                  Troubleshooting

                  Verified workflows and limits

                  -

                  The original accepted Station manual and its workflow claims are -preserved byte -for byte. Those results identify earlier artifacts; they are not -installed signoff for this naming candidate. The current package retains -the same Beta Python service and pinned CivicCast donor. Source presence -and a successful wheel import do not establish the required Windows -Meetings → Station → Records handoff.

                  -

                  The new candidate must verify actual saved meeting/agenda context, -authorized Station capture and stop, completed media/hash readback, -private Records handoff, idempotency, authorization/logout, persistence -and the agreed recovery path. Its ACCEPTANCE.md must distinguish new -proof from justified reused evidence. This source documentation does not -certify a signed MSI, live YouTube upload, physical PEG broadcast, city -deployment or long-duration commissioning.

                  +

                  The separately configured Station workflow was exercised on the original Windows 1.6.0.1 Beta 1. The follow-up Windows 1.6.0.1 Station delivery exercised encrypted live feed and recording delivery. The Windows 1.8.0.1 acceptance summary records the current MSI checks. Station capture and its Meetings-to-Records handoff were outside that run. Field equipment, city credentials, and live YouTube commissioning require separate local verification.

                  +

                  The separate provisioning/service boundary and existing external-service limits remain as described below. Staff remain responsible for official release and publication decisions. No @@ -1089,12 +1073,7 @@

                  Staff decisions and authority remains with the adopted source and responsible organization; imported amounts do not become a new authoritative calculation.

                  Beta operation and recovery

                  -

                  Use the identified candidate in its supported fresh-install scope. -Preserve backups and original evidence. Test physical equipment and -chosen network/service configuration before relying on them. The -supplied acceptance describes selected synthetic workflows, not every -screen, vendor, field condition or upgrade. Operators decide whether a -particular deployment meets their own operational obligations.

                  +

                  Windows 1.8.0.1 was tested for fresh installation and in-place upgrade from 1.7.2.1. Upgrade paths from versions older than 1.7.2.1 are unverified. Station uses its separately configured service. Keep backups and original evidence. Test your physical equipment and network and service configuration before relying on them. See the acceptance summary for the tested paths.

                  Warranty and liability

                  The covered software’s warranty and liability conditions are those in sections 15–17 of the supplied AGPL and any applicable separate written @@ -1566,4 +1545,4 @@

                  Delivery subject index

                  and reconciliation.
                3. Schema4: durable upload intent; existing evidence retained.
                  4. -

                  The resident portal is deployed separately. See the Townlight Portal Guide for its workflow and acceptance limits.

                  Townlight · AGPL-3.0-only · Candidate evidence applies only to its identified artifacts.
                  \ No newline at end of file +

                  The resident portal is deployed separately. See the Townlight Portal Guide for its workflow and acceptance limits.

                  \ No newline at end of file diff --git a/docs/beta-1/manuals/suite.html b/docs/beta-1/manuals/suite.html index 847b431..e97652b 100644 --- a/docs/beta-1/manuals/suite.html +++ b/docs/beta-1/manuals/suite.html @@ -1,16 +1,16 @@ Townlight Suite Manual | Townlight Windows Beta 1 +header .brand{display:inline-flex;align-items:center;max-width:100%;flex-shrink:0}header .brand img{display:block;width:217px;max-width:100%;height:auto} -
                  Townlight +
                  Townlight
                  @@ -127,12 +127,11 @@

                  Beta identity

                  Supported acceptance profile -Windows x64 fresh install; inspections-preview; separate Station -configuration +Windows x64 fresh install and upgrade from 1.7.2.1. Select the full profile. Station uses separate configuration. -

                  Start a new installation with an empty database and fresh Windows profile. For an upgrade from Windows 1.7.2.1, keep the existing profile. The approved profile path is %LOCALAPPDATA%\CivicSuite. Keep existing profiles and backups.

                  +

                  Component versions

                  @@ -198,21 +197,23 @@

                  Component versions

                  - - - - - + + + +
                  townlight-notice 0.3.0
                  Local runtimetownlight-runtime0.2.1
                  Boards & Commissionstownlight-boards0.2.0
                  Contractstownlight-contracts0.2.0
                  Procurementtownlight-procurement0.3.0
                  Local runtimetownlight-runtime0.3.0

                  First run

                  +

                  Upgrade from 1.7.2.1. For the tested upgrade from 1.7.2.1, back up city data and settings, close Townlight, run the signed Windows 1.8.0.1 MSI, and reopen Townlight under the same Windows account with its existing profile. Keep the existing %LOCALAPPDATA%\CivicSuite directory. Upgrade paths from versions older than 1.7.2.1 are unverified. Station uses its separately configured service.

                  +

                  Fresh installation

                  +

                  Run the signed Windows 1.8.0.1 MSI and use an empty database and a new Townlight profile for first run.

                  1. Download the signed MSI, matching source and checksums from the Windows x64 beta 1.8.0.1 release.
                  2. Verify the MSI hash and Authenticode publisher before installation. See the Windows acceptance summary for the tested setup.
                  3. Launch Townlight under the intended named Windows account. Choose the storage folders. Select Townlight Inspections candidate (inspections-preview) for the bounded -desktop composition, including Access and Notice. A narrower selection +desktop composition, including Access, Notice, Boards & Commissions, Contracts, and Procurement. A narrower selection will not expose all workspaces.
                  4. Enter the city profile, time zone and contacts. Create the first named local administrator, sign in and choose protected backup storage. @@ -230,7 +231,7 @@

                    First run

                    Configure vision explicitly only if automatic photo drafting is selected.
                  -

                  Daily workflow

                  +

                  Daily workflow

                  Windows staff workflow guide covers Boards & Commissions, Contracts and Procurement.

                  Sign in with your own named account. Confirm the selected workspace, open a saved record and check its source/version before editing. Save the work, record the intended review and inspect its audience. Use an @@ -417,8 +418,7 @@

                  Existing product operating

                  Technical specifications

                  Runtime and storage

                  -

                  The accepted package targets Windows x64 fresh -installation. Its native shell uses Rust 2021, Tauri 2 +

                  The accepted package supports Windows x64 fresh installation and upgrade from 1.7.2.1. Its native shell uses Rust 2021, Tauri 2 and Microsoft WebView2; browser assets are JavaScript built with Vite 8.1.6. This describes the native desktop frontend; Station has a separate React operator, specified below or in @@ -495,7 +495,7 @@

                  Native deployment

                  Use Setup, Settings and System Health for supported staff operation. Administrators provision folders, backup storage, named accounts and the city profile. Select inspections-preview for the bounded -desktop composition, including Access and Notice. Station remains a +desktop composition, including Access, Notice, Boards & Commissions, Contracts, and Procurement. Station remains a separate service boundary. Do not use a standalone product’s demo server as a substitute for the installed workspace.

                  Technical deployments use TOWNLIGHT_PRODUCT_PROFILE, @@ -642,7 +642,7 @@

                  Backup recovery and controls. If the result says Restore needs service start, use Start, then Check, and reopen a known record. Do not repeat restore merely because services -need to start. The fresh-profile acceptance verified that a fulfilled +need to start. The Windows 1.6.0.1 Beta 1 fresh-install acceptance verified that a fulfilled request survived restore and a post-backup marker did not.

                  Keep Station’s dedicated database and media evidence together in its own backup. Core’s native-profile backup must not be assumed to include @@ -723,6 +723,7 @@

                  Troubleshooting

                  Verified workflows and limits

                  +

                  The table records selected synthetic workflows from the original Windows 1.6.0.1 Beta 1 Sandbox run. Station’s later delivery has separate Windows 1.6.0.1 acceptance. See the Windows 1.8.0.1 acceptance summary for the workflows and upgrade path exercised on the current MSI.

                  @@ -802,15 +803,8 @@

                  Verified workflows and

                  -

                  The Windows acceptance summary records the installed Windows checks for this MSI. The earlier Station delivery evidence applies to its original build.

                  -

                  See the Windows acceptance summary for this MSI. The historical evidence index applies to its original build.

                  -

                  The limits remain: actual city field acceptance and equipment/network -commissioning; Station automatic provisioning/SCM commissioning; every -UI/role combination; field recognition accuracy; and historical in-place -upgrades are not certified. They are not five invented feature -requirements. Fresh-install controlled beta handoff remains the accepted -scope. This package makes no city-deployment, publication or -general-availability claim.

                  + +

                  The Windows 1.8.0.1 acceptance covers the tested installation paths and selected synthetic workflows, including Boards & Commissions, Contracts, and Procurement. Earlier results apply to their original builds. City field acceptance, physical equipment and network commissioning, Station automatic provisioning, and comprehensive UI and role coverage remain outside the 1.8.0.1 checks.

                  Terms of service and license

                  Scope and status

                  These terms describe the Townlight Beta 1 software and this @@ -869,12 +863,7 @@

                  Staff decisions and authority remains with the adopted source and responsible organization; imported amounts do not become a new authoritative calculation.

                  Beta operation and recovery

                  -

                  Use the identified candidate in its supported fresh-install scope. -Preserve backups and original evidence. Test physical equipment and -chosen network/service configuration before relying on them. The -supplied acceptance describes selected synthetic workflows, not every -screen, vendor, field condition or upgrade. Operators decide whether a -particular deployment meets their own operational obligations.

                  +

                  Windows 1.8.0.1 was tested for fresh installation and in-place upgrade from 1.7.2.1. Upgrade paths from versions older than 1.7.2.1 are unverified. Station uses its separately configured service. Keep backups and original evidence. Test your physical equipment and network and service configuration before relying on them. See the acceptance summary for the tested paths.

                  Warranty and liability

                  The covered software’s warranty and liability conditions are those in sections 15–17 of the supplied AGPL and any applicable separate written @@ -1095,4 +1084,4 @@

                  Delivery subject index

                  and reconciliation.
                4. Schema4: durable upload intent; existing evidence retained.
                  5. -

                  The resident portal is deployed separately. See the Townlight Portal Guide for its workflow and acceptance limits.

                  Townlight · AGPL-3.0-only · Candidate evidence applies only to its identified artifacts.
                  \ No newline at end of file +

                  The resident portal is deployed separately. See the Townlight Portal Guide for its workflow and acceptance limits.

                  \ No newline at end of file diff --git a/docs/beta-1/manuals/zoning.html b/docs/beta-1/manuals/zoning.html index c2db686..4b00a17 100644 --- a/docs/beta-1/manuals/zoning.html +++ b/docs/beta-1/manuals/zoning.html @@ -1,16 +1,16 @@ Townlight Zoning Manual | Townlight Windows Beta 1 +header .brand{display:inline-flex;align-items:center;max-width:100%;flex-shrink:0}header .brand img{display:block;width:217px;max-width:100%;height:auto} -
                  Townlight +
                  Townlight
                  @@ -161,13 +161,15 @@

                  Beta identity

                  Acceptance composition -Fresh Windows x64 profile; inspections-preview; Station configured -separately +Windows x64 fresh install and upgrade from 1.7.2.1. Select the full profile. Station uses separate configuration. -

                  Start a new installation with an empty database and fresh Windows profile. For an upgrade from Windows 1.7.2.1, keep the existing profile. The approved profile path is %LOCALAPPDATA%\CivicSuite. Keep existing profiles and backups.

                  +

                  First run

                  +

                  Upgrade from 1.7.2.1. For the tested upgrade from 1.7.2.1, back up city data and settings, close Townlight, run the signed Windows 1.8.0.1 MSI, and reopen Townlight under the same Windows account with its existing profile. Keep the existing %LOCALAPPDATA%\CivicSuite directory. Upgrade paths from versions older than 1.7.2.1 are unverified. Station uses its separately configured service.

                  +

                  Fresh installation

                  +

                  Run the signed Windows 1.8.0.1 MSI and use an empty database and a new Townlight profile for first run.

                  1. Download the signed MSI, matching source companion and checksums from the public Windows release.
                  2. Verify the MSI hash and Authenticode publisher before installation. See the Windows acceptance summary for the tested setup.
                    3. @@ -374,8 +376,7 @@

                    Use the existing and desktop Zoning view.

                    Technical specifications

                    Runtime and storage

                    -

                    The accepted package targets Windows x64 fresh -installation. Its native shell uses Rust 2021, Tauri 2 +

                    The accepted package supports Windows x64 fresh installation and upgrade from 1.7.2.1. Its native shell uses Rust 2021, Tauri 2 and Microsoft WebView2; browser assets are JavaScript built with Vite 8.1.6. This describes the native desktop frontend; Station has a separate React operator, specified below or in @@ -594,7 +595,7 @@

                    Backup recovery and controls. If the result says Restore needs service start, use Start, then Check, and reopen a known record. Do not repeat restore merely because services -need to start. The fresh-profile acceptance verified that a fulfilled +need to start. The Windows 1.6.0.1 Beta 1 fresh-install acceptance verified that a fulfilled request survived restore and a post-backup marker did not.

                    Keep Station’s dedicated database and media evidence together in its own backup. Core’s native-profile backup must not be assumed to include @@ -675,6 +676,7 @@

                    Troubleshooting

                    Verified workflows and limits

                    +

                    The table records selected synthetic workflows from the original Windows 1.6.0.1 Beta 1 Sandbox run. Station’s later delivery has separate Windows 1.6.0.1 acceptance. See the Windows 1.8.0.1 acceptance summary for the workflows and upgrade path exercised on the current MSI.

                    @@ -697,21 +699,8 @@

                    Verified workflows and

                    -

                    These results come from the identified signed candidate’s fresh -normal-profile Sandbox exercise: real native IPC/HTTP/PostgreSQL and -selected headless controls. All accounts, source bundles and media were -synthetic. The guest install/uninstall and recovery passed, and the -owned Sandbox stopped. No host installed application or standalone -CivicCast was changed. This documentation task reuses those receipts; it -does not claim a new software acceptance run.

                    -

                    See the Windows acceptance summary for this MSI. The historical evidence index applies to its original build.

                    -

                    The limits remain: actual city field acceptance and equipment/network -commissioning; Station automatic provisioning/SCM commissioning; every -UI/role combination; field recognition accuracy; and historical in-place -upgrades are not certified. They are not five invented feature -requirements. Fresh-install controlled beta handoff remains the accepted -scope. This package makes no city-deployment, publication or -general-availability claim.

                    + +

                    The Windows 1.8.0.1 acceptance covers the tested installation paths and selected synthetic workflows, including Boards & Commissions, Contracts, and Procurement. Earlier results apply to their original builds. City field acceptance, physical equipment and network commissioning, Station automatic provisioning, and comprehensive UI and role coverage remain outside the 1.8.0.1 checks.

                    Terms of service and license

                    Scope and status

                    These terms describe the Townlight Beta 1 software and this @@ -768,12 +757,7 @@

                    Staff decisions and authority remains with the adopted source and responsible organization; imported amounts do not become a new authoritative calculation.

                    Beta operation and recovery

                    -

                    Use the identified candidate in its supported fresh-install scope. -Preserve backups and original evidence. Test physical equipment and -chosen network/service configuration before relying on them. The -supplied acceptance describes selected synthetic workflows, not every -screen, vendor, field condition or upgrade. Operators decide whether a -particular deployment meets their own operational obligations.

                    +

                    Windows 1.8.0.1 was tested for fresh installation and in-place upgrade from 1.7.2.1. Upgrade paths from versions older than 1.7.2.1 are unverified. Station uses its separately configured service. Keep backups and original evidence. Test your physical equipment and network and service configuration before relying on them. See the acceptance summary for the tested paths.

                    Warranty and liability

                    The covered software’s warranty and liability conditions are those in sections 15–17 of the supplied AGPL and any applicable separate written @@ -979,4 +963,4 @@

                    Workflow subject index

                  3. Full AGPL text

                    4. -
                    Townlight · AGPL-3.0-only · Candidate evidence applies only to its identified artifacts.
                    \ No newline at end of file + \ No newline at end of file diff --git a/docs/beta-1/pdf/Townlight-Code-Manual-Beta-1.pdf b/docs/beta-1/pdf/Townlight-Code-Manual-Beta-1.pdf index c983d44..59e8c59 100644 Binary files a/docs/beta-1/pdf/Townlight-Code-Manual-Beta-1.pdf and b/docs/beta-1/pdf/Townlight-Code-Manual-Beta-1.pdf differ diff --git a/docs/beta-1/pdf/Townlight-Core-Manual-Beta-1.pdf b/docs/beta-1/pdf/Townlight-Core-Manual-Beta-1.pdf index 9715177..343c506 100644 Binary files a/docs/beta-1/pdf/Townlight-Core-Manual-Beta-1.pdf and b/docs/beta-1/pdf/Townlight-Core-Manual-Beta-1.pdf differ diff --git a/docs/beta-1/pdf/Townlight-Inspections-Manual-Beta-1.pdf b/docs/beta-1/pdf/Townlight-Inspections-Manual-Beta-1.pdf index 3766982..6297876 100644 Binary files a/docs/beta-1/pdf/Townlight-Inspections-Manual-Beta-1.pdf and b/docs/beta-1/pdf/Townlight-Inspections-Manual-Beta-1.pdf differ diff --git a/docs/beta-1/pdf/Townlight-Meetings-Manual-Beta-1.pdf b/docs/beta-1/pdf/Townlight-Meetings-Manual-Beta-1.pdf index 528531e..48c40ce 100644 Binary files a/docs/beta-1/pdf/Townlight-Meetings-Manual-Beta-1.pdf and b/docs/beta-1/pdf/Townlight-Meetings-Manual-Beta-1.pdf differ diff --git a/docs/beta-1/pdf/Townlight-Permitting-Manual-Beta-1.pdf b/docs/beta-1/pdf/Townlight-Permitting-Manual-Beta-1.pdf index c136b91..4a5578c 100644 Binary files a/docs/beta-1/pdf/Townlight-Permitting-Manual-Beta-1.pdf and b/docs/beta-1/pdf/Townlight-Permitting-Manual-Beta-1.pdf differ diff --git a/docs/beta-1/pdf/Townlight-Planning-Manual-Beta-1.pdf b/docs/beta-1/pdf/Townlight-Planning-Manual-Beta-1.pdf index 4c58751..9aa41ae 100644 Binary files a/docs/beta-1/pdf/Townlight-Planning-Manual-Beta-1.pdf and b/docs/beta-1/pdf/Townlight-Planning-Manual-Beta-1.pdf differ diff --git a/docs/beta-1/pdf/Townlight-Records-Manual-Beta-1.pdf b/docs/beta-1/pdf/Townlight-Records-Manual-Beta-1.pdf index fb3861b..5ded0bd 100644 Binary files a/docs/beta-1/pdf/Townlight-Records-Manual-Beta-1.pdf and b/docs/beta-1/pdf/Townlight-Records-Manual-Beta-1.pdf differ diff --git a/docs/beta-1/pdf/Townlight-Station-Manual-Beta-1.pdf b/docs/beta-1/pdf/Townlight-Station-Manual-Beta-1.pdf index 7541da7..9ddb216 100644 Binary files a/docs/beta-1/pdf/Townlight-Station-Manual-Beta-1.pdf and b/docs/beta-1/pdf/Townlight-Station-Manual-Beta-1.pdf differ diff --git a/docs/beta-1/pdf/Townlight-Suite-Manual-Beta-1.pdf b/docs/beta-1/pdf/Townlight-Suite-Manual-Beta-1.pdf index ecea76e..fbc6186 100644 Binary files a/docs/beta-1/pdf/Townlight-Suite-Manual-Beta-1.pdf and b/docs/beta-1/pdf/Townlight-Suite-Manual-Beta-1.pdf differ diff --git a/docs/beta-1/pdf/Townlight-Zoning-Manual-Beta-1.pdf b/docs/beta-1/pdf/Townlight-Zoning-Manual-Beta-1.pdf index 013951f..016ef9a 100644 Binary files a/docs/beta-1/pdf/Townlight-Zoning-Manual-Beta-1.pdf and b/docs/beta-1/pdf/Townlight-Zoning-Manual-Beta-1.pdf differ diff --git a/docs/beta-1/products/access/index.html b/docs/beta-1/products/access/index.html index e91058a..488047c 100644 --- a/docs/beta-1/products/access/index.html +++ b/docs/beta-1/products/access/index.html @@ -1 +1 @@ -Townlight Access | Townlight Beta 1
                    townlightTownlight Beta 1
                    Townlight Access · Townlight Beta 1

                    Review the source and preserve the advice.

                    Retain reviewed source, advice and draft provenance for human review.

                    Read the manualPrintable manualWord manual
                    townlight-access 0.5.0AGPL-3.0-onlyBeta evaluation · Windows fresh-install scope

                    The bounded staff workflow

                    1. Save and reopen an accessibility review with its actual source, findings and saved model advice.
                    2. Retain plain-language or translation drafts with source/output, language, model, staff actor and review status.
                    3. Export the complete Markdown record with verified bytes; attach the actual file through Records when authorized.

                    The Windows local-model workflow differs from the standalone service, whose language samples are explicitly not translations of the input. Human review remains required. Access does not certify ADA compliance or publish text.

                    Evidence rather than promises

                    Windows Sandbox acceptance passed.

                    The Windows acceptance summary describes the fresh Windows install, staff workflow, and 1.7.2.1 upgrade checks. See its scope for coverage of other workflows and equipment.

                    Read the exact acceptance and limits →

                    Ready to evaluate?

                    Begin with the current manual and download the Windows x64 beta 1.8.0.1. Configure the chosen test site and have its staff review source applicability and run the existing workflows.

                    Detailed READMEVersions and provenance
                    \ No newline at end of file +Townlight Access | Townlight Beta 1
                    townlightTownlight Beta 1
                    Townlight Access · Townlight Beta 1

                    Review the source and preserve the advice.

                    Retain reviewed source, advice and draft provenance for human review.

                    Read the manualPrintable manualWord manual
                    townlight-access 0.5.0AGPL-3.0-onlyBeta evaluation · Windows fresh install and tested 1.7.2.1 upgrade

                    The bounded staff workflow

                    1. Save and reopen an accessibility review with its actual source, findings and saved model advice.
                    2. Retain plain-language or translation drafts with source/output, language, model, staff actor and review status.
                    3. Export the complete Markdown record with verified bytes; attach the actual file through Records when authorized.

                    The Windows local-model workflow differs from the standalone service, whose language samples are explicitly not translations of the input. Human review remains required. Access does not certify ADA compliance or publish text.

                    Evidence rather than promises

                    Windows Sandbox acceptance passed.

                    The Windows acceptance summary describes the fresh Windows install, staff workflow, and 1.7.2.1 upgrade checks. See its scope for coverage of other workflows and equipment.

                    Read the exact acceptance and limits →

                    Ready to evaluate?

                    Begin with the current manual and download the Windows x64 beta 1.8.0.1. Configure the chosen test site and have its staff review source applicability and run the existing workflows.

                    Detailed READMEVersions and provenance
                    \ No newline at end of file diff --git a/docs/beta-1/products/code/index.html b/docs/beta-1/products/code/index.html index a8ebc85..1491a1d 100644 --- a/docs/beta-1/products/code/index.html +++ b/docs/beta-1/products/code/index.html @@ -1 +1 @@ -Townlight Code | Townlight Beta 1
                    townlightTownlight Beta 1
                    Townlight Code · Townlight Beta 1

                    Trace every section to its source and history.

                    Code imports and preserves municipal code sources, supplies exact citations and version history, and connects proposed legislation to Meetings. Authorized staff separately record adoption evidence and codification.

                    Read the manualPrintable manualWord manualTechnical reference
                    townlight-code 1.0.9AGPL-3.0-onlyBeta evaluation · Windows fresh-install scope
                    For Code custodians, clerks, legal reviewers and staff seeking cited authority

                    What the workflow delivers

                    1. Import a source. Inspect the complete bundle JSON for jurisdiction, section identifiers, source/effective dates, original name and hashes before selecting Import. Import submits directly; inspect the saved import and provenance afterward. There is no separate preview/confirmation step.
                    2. Find the exact section. Search the topic and open the cited section. Check the requested as-of date and version. Keep explanatory wording separate from the retained source text.
                    3. Inspect provenance. Read import history, original source and section history. Export the exact cited source when it is needed for a staff workpaper or Records evidence.
                    4. Connect a proposal. Create the existing Code–Meetings connection for the actual proposal and agenda context. Retain the connection identifier and keep pending text distinct from adopted code.

                    Connected evidence

                    Receives Meetings decision evidence. Supplies permitted cited material to Records, Zoning, Permitting and Inspections. Planning’s selected installed evidence providers are Meetings and Zoning; no separate direct Code connection is implied.

                    Know the beta boundary

                    An imported document is not automatically adopted law. Local imports and orchestration do not establish a live agreement with every commercial codifier. Human approval and authoritative source applicability remain necessary.

                    Architecture

                    Where the evidence goes

                    Townlight Code architecture and evidence flow

                    Receives Meetings decision evidence. Supplies permitted cited material to Records, Zoning, Permitting and Inspections. Planning’s selected installed evidence providers are Meetings and Zoning; no separate direct Code connection is implied.

                    Evidence rather than promises

                    Windows Sandbox acceptance passed.

                    The Windows acceptance summary describes the fresh Windows install, staff workflow, and 1.7.2.1 upgrade checks. See its scope for coverage of other workflows and equipment.

                    Read the exact acceptance and limits →

                    Ready to evaluate?

                    Begin with the current manual and download the Windows x64 beta 1.8.0.1. Configure the chosen test site and have its staff review source applicability and run the existing workflows.

                    Detailed READMEVersions and provenance
                    \ No newline at end of file +Townlight Code | Townlight Beta 1
                    townlightTownlight Beta 1
                    Townlight Code · Townlight Beta 1

                    Trace every section to its source and history.

                    Code imports and preserves municipal code sources, supplies exact citations and version history, and connects proposed legislation to Meetings. Authorized staff separately record adoption evidence and codification.

                    Read the manualPrintable manualWord manualTechnical reference
                    townlight-code 1.0.9AGPL-3.0-onlyBeta evaluation · Windows fresh install and tested 1.7.2.1 upgrade
                    For Code custodians, clerks, legal reviewers and staff seeking cited authority

                    What the workflow delivers

                    1. Import a source. Inspect the complete bundle JSON for jurisdiction, section identifiers, source/effective dates, original name and hashes before selecting Import. Import submits directly; inspect the saved import and provenance afterward. There is no separate preview/confirmation step.
                    2. Find the exact section. Search the topic and open the cited section. Check the requested as-of date and version. Keep explanatory wording separate from the retained source text.
                    3. Inspect provenance. Read import history, original source and section history. Export the exact cited source when it is needed for a staff workpaper or Records evidence.
                    4. Connect a proposal. Create the existing Code–Meetings connection for the actual proposal and agenda context. Retain the connection identifier and keep pending text distinct from adopted code.

                    Connected evidence

                    Receives Meetings decision evidence. Supplies permitted cited material to Records, Zoning, Permitting and Inspections. Planning’s selected installed evidence providers are Meetings and Zoning; no separate direct Code connection is implied.

                    Know the beta boundary

                    An imported document is not automatically adopted law. Local imports and orchestration do not establish a live agreement with every commercial codifier. Human approval and authoritative source applicability remain necessary.

                    Architecture

                    Where the evidence goes

                    Townlight Code architecture and evidence flow

                    Receives Meetings decision evidence. Supplies permitted cited material to Records, Zoning, Permitting and Inspections. Planning’s selected installed evidence providers are Meetings and Zoning; no separate direct Code connection is implied.

                    Evidence rather than promises

                    Windows Sandbox acceptance passed.

                    The Windows acceptance summary describes the fresh Windows install, staff workflow, and 1.7.2.1 upgrade checks. See its scope for coverage of other workflows and equipment.

                    Read the exact acceptance and limits →

                    Ready to evaluate?

                    Begin with the current manual and download the Windows x64 beta 1.8.0.1. Configure the chosen test site and have its staff review source applicability and run the existing workflows.

                    Detailed READMEVersions and provenance
                    \ No newline at end of file diff --git a/docs/beta-1/products/core/index.html b/docs/beta-1/products/core/index.html index 397675e..99b524c 100644 --- a/docs/beta-1/products/core/index.html +++ b/docs/beta-1/products/core/index.html @@ -1 +1 @@ -Townlight Core | Townlight Beta 1
                    townlightTownlight Beta 1
                    Townlight Core · Townlight Beta 1

                    A shared foundation for accountable municipal work.

                    Core provides the shared contracts, ingestion, identity helpers, task infrastructure and recovery foundation used by Townlight. Staff encounter these capabilities through Setup, Settings and System Health. Business decisions stay with their owning product.

                    Read the manualPrintable manualWord manualTechnical reference
                    townlight-core 1.3.0.dev2AGPL-3.0-onlyBeta evaluation · Windows fresh-install scope
                    For IT administrators and platform maintainers

                    What the workflow delivers

                    1. Complete setup. Choose folders and the full product composition. Create the city profile and the first named administrator. Choose a protected backup location. Defer optional local AI if it is not needed.
                    2. Activate the runtime. Run the first-run health check, wait for readiness and open Townlight. In System Health select Finish Records Migration to activate the canonical Python and PostgreSQL services. A running process alone is not a ready database.
                    3. Create staff access. Use Settings to create named staff. Sign out and confirm that staff can sign in with their own account. Keep administrator privileges with people responsible for setup; ordinary staff cannot administer users.
                    4. Import through the right product. Use the source library of Code, Zoning, Planning or Permitting. Inspect provenance and permissions there. Core ingestion helpers do not bypass the owning product’s source review.

                    Connected evidence

                    All products use selected Core contracts. Core does not create unrestricted access between products. Access and Notice provide the bounded staff workflows described in their current manuals and acceptance summary.

                    Know the beta boundary

                    Shared catalog, exemption and module-generator code exists in the released Windows beta. It is not a centrally hosted federation service. A business product still owns its decisions, identity mapping and permission checks. Historical placeholder ADRs are retained as history, rather than descriptions of the current implementation.

                    Architecture

                    Where the evidence goes

                    Townlight Core architecture and evidence flow

                    All products use selected Core contracts. Core does not create unrestricted access between products. Access and Notice provide the bounded staff workflows described in their current manuals and acceptance summary.

                    Evidence rather than promises

                    Windows Sandbox acceptance passed.

                    The Windows acceptance summary describes the fresh Windows install, staff workflow, and 1.7.2.1 upgrade checks. See its scope for coverage of other workflows and equipment.

                    Read the exact acceptance and limits →

                    Ready to evaluate?

                    Begin with the current manual and download the Windows x64 beta 1.8.0.1. Configure the chosen test site and have its staff review source applicability and run the existing workflows.

                    Detailed READMEVersions and provenance
                    \ No newline at end of file +Townlight Core | Townlight Beta 1
                    townlightTownlight Beta 1
                    Townlight Core · Townlight Beta 1

                    A shared foundation for accountable municipal work.

                    Core provides the shared contracts, ingestion, identity helpers, task infrastructure and recovery foundation used by Townlight. Staff encounter these capabilities through Setup, Settings and System Health. Business decisions stay with their owning product.

                    Read the manualPrintable manualWord manualTechnical reference
                    townlight-core 1.3.0.dev2AGPL-3.0-onlyBeta evaluation · Windows fresh install and tested 1.7.2.1 upgrade
                    For IT administrators and platform maintainers

                    What the workflow delivers

                    1. Complete setup. Choose folders and the full product composition. Create the city profile and the first named administrator. Choose a protected backup location. Defer optional local AI if it is not needed.
                    2. Activate the runtime. Run the first-run health check, wait for readiness and open Townlight. In System Health select Finish Records Migration to activate the canonical Python and PostgreSQL services. A running process alone is not a ready database.
                    3. Create staff access. Use Settings to create named staff. Sign out and confirm that staff can sign in with their own account. Keep administrator privileges with people responsible for setup; ordinary staff cannot administer users.
                    4. Import through the right product. Use the source library of Code, Zoning, Planning or Permitting. Inspect provenance and permissions there. Core ingestion helpers do not bypass the owning product’s source review.

                    Connected evidence

                    All products use selected Core contracts. Core does not create unrestricted access between products. Access and Notice provide the bounded staff workflows described in their current manuals and acceptance summary.

                    Know the beta boundary

                    Shared catalog, exemption and module-generator code exists in the released Windows beta. It is not a centrally hosted federation service. A business product still owns its decisions, identity mapping and permission checks. Historical placeholder ADRs are retained as history, rather than descriptions of the current implementation.

                    Architecture

                    Where the evidence goes

                    Townlight Core architecture and evidence flow

                    All products use selected Core contracts. Core does not create unrestricted access between products. Access and Notice provide the bounded staff workflows described in their current manuals and acceptance summary.

                    Evidence rather than promises

                    Windows Sandbox acceptance passed.

                    The Windows acceptance summary describes the fresh Windows install, staff workflow, and 1.7.2.1 upgrade checks. See its scope for coverage of other workflows and equipment.

                    Read the exact acceptance and limits →

                    Ready to evaluate?

                    Begin with the current manual and download the Windows x64 beta 1.8.0.1. Configure the chosen test site and have its staff review source applicability and run the existing workflows.

                    Detailed READMEVersions and provenance
                    \ No newline at end of file diff --git a/docs/beta-1/products/inspections/index.html b/docs/beta-1/products/inspections/index.html index 6bf07e9..caa3930 100644 --- a/docs/beta-1/products/inspections/index.html +++ b/docs/beta-1/products/inspections/index.html @@ -1 +1 @@ -Townlight Inspections | Townlight Beta 1
                    townlightTownlight Beta 1
                    Townlight Inspections · Townlight Beta 1

                    Preserve evidence and review every draft finding.

                    Inspections retains original evidence, supplied observations and optional configured photo/audio analysis, then supports reviewed case workpapers and a separate Records copy. Automatic output is a draft for inspector review.

                    Read the manualPrintable manualWord manualTechnical reference
                    townlight-inspections 0.3.0+dev.2AGPL-3.0-onlyBeta evaluation · Windows fresh-install scope
                    For Inspectors and authorized reviewing staff

                    What the workflow delivers

                    1. Create the case. Enter the property/case context and inspector observations. Keep staff-only notes and identifiers in their intended fields. Save before moving away from the workspace.
                    2. Retain originals. Add original supported files using the existing evidence control. Inspect the filename, size and retained hash. Preserve originals separately from any derivative draft.
                    3. Choose supplied or automatic text. Use supplied photo observations and a supplied voice summary for deterministic work. If configured, Analyse originals calls the image-capable provider and bundled audio transcriber. Read unavailable/failed results as such; do not label supplied text automatic.
                    4. Review the analysis and citations. Compare automatic wording to the original evidence. Correct errors, uncertainty and Code citations. A model output is neither an official finding nor a notice.

                    Connected evidence

                    Consumes cited Code and Core contracts; supplies a reviewed copy to Records. It does not imply an automatic permit-system or enforcement-system writeback.

                    Know the beta boundary

                    The bundled Whistle CPU engine executes raw-audio transcription. Automatic photo analysis requires explicit vision configuration; missing configuration reports unavailable. Synthetic execution proves that adapters run, not field recognition accuracy. No official citation/fine issuance, inspection scheduling or enforcement-system writeback is provided.

                    Architecture

                    Where the evidence goes

                    Townlight Inspections architecture and evidence flow

                    Consumes cited Code and Core contracts; supplies a reviewed copy to Records. It does not imply an automatic permit-system or enforcement-system writeback.

                    Evidence rather than promises

                    Windows Sandbox acceptance passed.

                    The Windows acceptance summary describes the fresh Windows install, staff workflow, and 1.7.2.1 upgrade checks. See its scope for coverage of other workflows and equipment.

                    Read the exact acceptance and limits →

                    Ready to evaluate?

                    Begin with the current manual and download the Windows x64 beta 1.8.0.1. Configure the chosen test site and have its staff review source applicability and run the existing workflows.

                    Detailed READMEVersions and provenance
                    \ No newline at end of file +Townlight Inspections | Townlight Beta 1
                    townlightTownlight Beta 1
                    Townlight Inspections · Townlight Beta 1

                    Preserve evidence and review every draft finding.

                    Inspections retains original evidence, supplied observations and optional configured photo/audio analysis, then supports reviewed case workpapers and a separate Records copy. Automatic output is a draft for inspector review.

                    Read the manualPrintable manualWord manualTechnical reference
                    townlight-inspections 0.3.0+dev.2AGPL-3.0-onlyBeta evaluation · Windows fresh install and tested 1.7.2.1 upgrade
                    For Inspectors and authorized reviewing staff

                    What the workflow delivers

                    1. Create the case. Enter the property/case context and inspector observations. Keep staff-only notes and identifiers in their intended fields. Save before moving away from the workspace.
                    2. Retain originals. Add original supported files using the existing evidence control. Inspect the filename, size and retained hash. Preserve originals separately from any derivative draft.
                    3. Choose supplied or automatic text. Use supplied photo observations and a supplied voice summary for deterministic work. If configured, Analyse originals calls the image-capable provider and bundled audio transcriber. Read unavailable/failed results as such; do not label supplied text automatic.
                    4. Review the analysis and citations. Compare automatic wording to the original evidence. Correct errors, uncertainty and Code citations. A model output is neither an official finding nor a notice.

                    Connected evidence

                    Consumes cited Code and Core contracts; supplies a reviewed copy to Records. It does not imply an automatic permit-system or enforcement-system writeback.

                    Know the beta boundary

                    The bundled Whistle CPU engine executes raw-audio transcription. Automatic photo analysis requires explicit vision configuration; missing configuration reports unavailable. Synthetic execution proves that adapters run, not field recognition accuracy. No official citation/fine issuance, inspection scheduling or enforcement-system writeback is provided.

                    Architecture

                    Where the evidence goes

                    Townlight Inspections architecture and evidence flow

                    Consumes cited Code and Core contracts; supplies a reviewed copy to Records. It does not imply an automatic permit-system or enforcement-system writeback.

                    Evidence rather than promises

                    Windows Sandbox acceptance passed.

                    The Windows acceptance summary describes the fresh Windows install, staff workflow, and 1.7.2.1 upgrade checks. See its scope for coverage of other workflows and equipment.

                    Read the exact acceptance and limits →

                    Ready to evaluate?

                    Begin with the current manual and download the Windows x64 beta 1.8.0.1. Configure the chosen test site and have its staff review source applicability and run the existing workflows.

                    Detailed READMEVersions and provenance
                    \ No newline at end of file diff --git a/docs/beta-1/products/meetings/index.html b/docs/beta-1/products/meetings/index.html index c756636..2e454c8 100644 --- a/docs/beta-1/products/meetings/index.html +++ b/docs/beta-1/products/meetings/index.html @@ -1 +1 @@ -Townlight Meetings | Townlight Beta 1
                    townlightTownlight Beta 1
                    Townlight Meetings · Townlight Beta 1

                    Keep the agenda, decisions and evidence connected.

                    Meetings supports clerk preparation and the retained proceedings of a meeting: agenda items, packets, motions, votes, supplied transcript material, minutes decisions and archives. It supplies canonical meeting and agenda context to Station.

                    Read the manualPrintable manualWord manualTechnical reference
                    townlight-meetings 1.0.5AGPL-3.0-onlyBeta evaluation · Windows fresh-install scope
                    For Clerks, meeting coordinators and authorized reviewers

                    What the workflow delivers

                    1. Create the meeting. Enter its title, date/time including the intended time zone, location and meeting type. Save and reopen it before adding downstream evidence.
                    2. Prepare the agenda and packet. Create agenda items, assign them to the actual meeting and record review. Assemble a packet from the selected items and source documents. Check the saved assembly’s packet identifier before using it for an archive or delivery.
                    3. Record notice work. Use the existing notice checklist, template and posting-proof controls where applicable. A calculated checklist is evidence for clerk review; staff verify the jurisdiction’s notice requirements and actual posting.
                    4. Record proceedings. Capture the actual motion, seconder and votes. Record corrections as corrections, preserving the earlier event. Retain supplied transcript text with its source label.

                    Connected evidence

                    Provides evidence to Records, Code, Zoning and Planning, and meeting identity to Station. Code adoption and codification remain separate. Supporting Notice and Access do not replace clerk review.

                    Know the beta boundary

                    Supplied transcript handling is not automatic audio transcription. Station adds capture; it does not imply a Meetings livestream hosting service. Vendor sync code and adapters are not proof that every vendor is configured or live.

                    Architecture

                    Where the evidence goes

                    Townlight Meetings architecture and evidence flow

                    Provides evidence to Records, Code, Zoning and Planning, and meeting identity to Station. Code adoption and codification remain separate. Supporting Notice and Access do not replace clerk review.

                    Evidence rather than promises

                    Windows Sandbox acceptance passed.

                    The Windows acceptance summary describes the fresh Windows install, staff workflow, and 1.7.2.1 upgrade checks. See its scope for coverage of other workflows and equipment.

                    Read the exact acceptance and limits →

                    Ready to evaluate?

                    Begin with the current manual and download the Windows x64 beta 1.8.0.1. Configure the chosen test site and have its staff review source applicability and run the existing workflows.

                    Detailed READMEVersions and provenance

                    The resident portal is deployed separately. See the Townlight Portal Guide for its workflow and acceptance limits.

                    \ No newline at end of file +Townlight Meetings | Townlight Beta 1
                    townlightTownlight Beta 1
                    Townlight Meetings · Townlight Beta 1

                    Keep the agenda, decisions and evidence connected.

                    Meetings supports clerk preparation and the retained proceedings of a meeting: agenda items, packets, motions, votes, supplied transcript material, minutes decisions and archives. It supplies canonical meeting and agenda context to Station.

                    Read the manualPrintable manualWord manualTechnical reference
                    townlight-meetings 1.0.5AGPL-3.0-onlyBeta evaluation · Windows fresh install and tested 1.7.2.1 upgrade
                    For Clerks, meeting coordinators and authorized reviewers

                    What the workflow delivers

                    1. Create the meeting. Enter its title, date/time including the intended time zone, location and meeting type. Save and reopen it before adding downstream evidence.
                    2. Prepare the agenda and packet. Create agenda items, assign them to the actual meeting and record review. Assemble a packet from the selected items and source documents. Check the saved assembly’s packet identifier before using it for an archive or delivery.
                    3. Record notice work. Use the existing notice checklist, template and posting-proof controls where applicable. A calculated checklist is evidence for clerk review; staff verify the jurisdiction’s notice requirements and actual posting.
                    4. Record proceedings. Capture the actual motion, seconder and votes. Record corrections as corrections, preserving the earlier event. Retain supplied transcript text with its source label.

                    Connected evidence

                    Provides evidence to Records, Code, Zoning and Planning, and meeting identity to Station. Code adoption and codification remain separate. Supporting Notice and Access do not replace clerk review.

                    Know the beta boundary

                    Supplied transcript handling is not automatic audio transcription. Station adds capture; it does not imply a Meetings livestream hosting service. Vendor sync code and adapters are not proof that every vendor is configured or live.

                    Architecture

                    Where the evidence goes

                    Townlight Meetings architecture and evidence flow

                    Provides evidence to Records, Code, Zoning and Planning, and meeting identity to Station. Code adoption and codification remain separate. Supporting Notice and Access do not replace clerk review.

                    Evidence rather than promises

                    Windows Sandbox acceptance passed.

                    The Windows acceptance summary describes the fresh Windows install, staff workflow, and 1.7.2.1 upgrade checks. See its scope for coverage of other workflows and equipment.

                    Read the exact acceptance and limits →

                    Ready to evaluate?

                    Begin with the current manual and download the Windows x64 beta 1.8.0.1. Configure the chosen test site and have its staff review source applicability and run the existing workflows.

                    Detailed READMEVersions and provenance

                    The resident portal is deployed separately. See the Townlight Portal Guide for its workflow and acceptance limits.

                    \ No newline at end of file diff --git a/docs/beta-1/products/notice/index.html b/docs/beta-1/products/notice/index.html index 68f1e98..27fe8fc 100644 --- a/docs/beta-1/products/notice/index.html +++ b/docs/beta-1/products/notice/index.html @@ -1 +1 @@ -Townlight Notice | Townlight Beta 1
                    townlightTownlight Beta 1
                    Townlight Notice · Townlight Beta 1

                    Keep review, posting proof and the archive connected.

                    Review, approve and retain actual posting proof and a verified archive.

                    Read the manualPrintable manualWord manual
                    townlight-notice 0.3.0AGPL-3.0-onlyBeta evaluation · Windows fresh-install scope

                    The bounded staff workflow

                    1. Save the actual notice and staff-selected deadline workpaper.
                    2. Review and approve the saved content; mechanical checks never establish legal approval.
                    3. After official publication outside Townlight, retain actual proof files with location and posting time.
                    4. Create and verify the archive, then explicitly attach it to the intended Records request with both Notice and Records authority.

                    Content edits invalidate current approval while preserving history. Subscriber delivery, official publication and jurisdiction-specific legal administration are outside this bounded workflow.

                    Evidence rather than promises

                    Windows Sandbox acceptance passed.

                    The Windows acceptance summary describes the fresh Windows install, staff workflow, and 1.7.2.1 upgrade checks. See its scope for coverage of other workflows and equipment.

                    Read the exact acceptance and limits →

                    Ready to evaluate?

                    Begin with the current manual and download the Windows x64 beta 1.8.0.1. Configure the chosen test site and have its staff review source applicability and run the existing workflows.

                    Detailed READMEVersions and provenance
                    \ No newline at end of file +Townlight Notice | Townlight Beta 1
                    townlightTownlight Beta 1
                    Townlight Notice · Townlight Beta 1

                    Keep review, posting proof and the archive connected.

                    Review, approve and retain actual posting proof and a verified archive.

                    Read the manualPrintable manualWord manual
                    townlight-notice 0.3.0AGPL-3.0-onlyBeta evaluation · Windows fresh install and tested 1.7.2.1 upgrade

                    The bounded staff workflow

                    1. Save the actual notice and staff-selected deadline workpaper.
                    2. Review and approve the saved content; mechanical checks never establish legal approval.
                    3. After official publication outside Townlight, retain actual proof files with location and posting time.
                    4. Create and verify the archive, then explicitly attach it to the intended Records request with both Notice and Records authority.

                    Content edits invalidate current approval while preserving history. Subscriber delivery, official publication and jurisdiction-specific legal administration are outside this bounded workflow.

                    Evidence rather than promises

                    Windows Sandbox acceptance passed.

                    The Windows acceptance summary describes the fresh Windows install, staff workflow, and 1.7.2.1 upgrade checks. See its scope for coverage of other workflows and equipment.

                    Read the exact acceptance and limits →

                    Ready to evaluate?

                    Begin with the current manual and download the Windows x64 beta 1.8.0.1. Configure the chosen test site and have its staff review source applicability and run the existing workflows.

                    Detailed READMEVersions and provenance
                    \ No newline at end of file diff --git a/docs/beta-1/products/permitting/index.html b/docs/beta-1/products/permitting/index.html index 932ef0e..fb2a1b9 100644 --- a/docs/beta-1/products/permitting/index.html +++ b/docs/beta-1/products/permitting/index.html @@ -1 +1 @@ -Townlight Permitting | Townlight Beta 1
                    townlightTownlight Beta 1
                    Townlight Permitting · Townlight Beta 1

                    Prepare a complete, cited intake for staff review.

                    Permitting supports pre-application and development-review intake. It imports retained requirements, produces source-grounded material/pathway guidance, saves reviewed cases and prepares a separate Records copy.

                    Read the manualPrintable manualWord manualTechnical reference
                    townlight-permitting 0.3.0+dev.2AGPL-3.0-onlyBeta evaluation · Windows fresh-install scope
                    For Permit intake staff and development-review coordinators

                    What the workflow delivers

                    1. Import requirements. Open Requirement library and select the complete JSON RequirementBundle. Inspect jurisdiction, project type, effective/source dates, original filename/hash and material citations. Later revisions require the current revision and preserve history.
                    2. Read pathway guidance. Choose the retained requirement revision and matching project type. Inspect material requirements, pathway steps and source-backed timing/fee text. If authority is absent, seek the source; do not invent a requirement, date or fee.
                    3. Prepare intake. Create the case with project, location, applicant contact and staff assignment. Assess materials as not reviewed, provided, missing or unclear. Keep private notes and the proposal separate from the public summary.
                    4. Select cited context. Search Code and Zoning and choose the exact permitted versions. Source availability and expected hashes are checked during search, save and export.

                    Connected evidence

                    Consumes Code and Zoning evidence and hands a reviewed Records copy to an existing request. There is no automatic creation of an Inspections case.

                    Know the beta boundary

                    Does not issue permits, collect money, calculate authoritative permit fees, schedule inspections or write decisions to a commercial permit system. Imported official fee amounts or fee-source wording are information from their source, not a new authoritative calculation. Universal vendor status mirroring and an internet applicant portal are outside this beta scope.

                    Architecture

                    Where the evidence goes

                    Townlight Permitting architecture and evidence flow

                    Consumes Code and Zoning evidence and hands a reviewed Records copy to an existing request. There is no automatic creation of an Inspections case.

                    Evidence rather than promises

                    Windows Sandbox acceptance passed.

                    The Windows acceptance summary describes the fresh Windows install, staff workflow, and 1.7.2.1 upgrade checks. See its scope for coverage of other workflows and equipment.

                    Read the exact acceptance and limits →

                    Ready to evaluate?

                    Begin with the current manual and download the Windows x64 beta 1.8.0.1. Configure the chosen test site and have its staff review source applicability and run the existing workflows.

                    Detailed READMEVersions and provenance
                    \ No newline at end of file +Townlight Permitting | Townlight Beta 1
                    townlightTownlight Beta 1
                    Townlight Permitting · Townlight Beta 1

                    Prepare a complete, cited intake for staff review.

                    Permitting supports pre-application and development-review intake. It imports retained requirements, produces source-grounded material/pathway guidance, saves reviewed cases and prepares a separate Records copy.

                    Read the manualPrintable manualWord manualTechnical reference
                    townlight-permitting 0.3.0+dev.2AGPL-3.0-onlyBeta evaluation · Windows fresh install and tested 1.7.2.1 upgrade
                    For Permit intake staff and development-review coordinators

                    What the workflow delivers

                    1. Import requirements. Open Requirement library and select the complete JSON RequirementBundle. Inspect jurisdiction, project type, effective/source dates, original filename/hash and material citations. Later revisions require the current revision and preserve history.
                    2. Read pathway guidance. Choose the retained requirement revision and matching project type. Inspect material requirements, pathway steps and source-backed timing/fee text. If authority is absent, seek the source; do not invent a requirement, date or fee.
                    3. Prepare intake. Create the case with project, location, applicant contact and staff assignment. Assess materials as not reviewed, provided, missing or unclear. Keep private notes and the proposal separate from the public summary.
                    4. Select cited context. Search Code and Zoning and choose the exact permitted versions. Source availability and expected hashes are checked during search, save and export.

                    Connected evidence

                    Consumes Code and Zoning evidence and hands a reviewed Records copy to an existing request. There is no automatic creation of an Inspections case.

                    Know the beta boundary

                    Does not issue permits, collect money, calculate authoritative permit fees, schedule inspections or write decisions to a commercial permit system. Imported official fee amounts or fee-source wording are information from their source, not a new authoritative calculation. Universal vendor status mirroring and an internet applicant portal are outside this beta scope.

                    Architecture

                    Where the evidence goes

                    Townlight Permitting architecture and evidence flow

                    Consumes Code and Zoning evidence and hands a reviewed Records copy to an existing request. There is no automatic creation of an Inspections case.

                    Evidence rather than promises

                    Windows Sandbox acceptance passed.

                    The Windows acceptance summary describes the fresh Windows install, staff workflow, and 1.7.2.1 upgrade checks. See its scope for coverage of other workflows and equipment.

                    Read the exact acceptance and limits →

                    Ready to evaluate?

                    Begin with the current manual and download the Windows x64 beta 1.8.0.1. Configure the chosen test site and have its staff review source applicability and run the existing workflows.

                    Detailed READMEVersions and provenance
                    \ No newline at end of file diff --git a/docs/beta-1/products/planning/index.html b/docs/beta-1/products/planning/index.html index 80c4a17..62783ad 100644 --- a/docs/beta-1/products/planning/index.html +++ b/docs/beta-1/products/planning/index.html @@ -1 +1 @@ -Townlight Planning | Townlight Beta 1
                    townlightTownlight Beta 1
                    Townlight Planning · Townlight Beta 1

                    Connect policy, analysis and municipal progress.

                    Planning retains adopted policy imports and neighborhood applicability, saved staff analyses, reviewed snapshots, municipal initiatives and amendment history. An analysis or amendment draft does not adopt policy.

                    Read the manualPrintable manualWord manualTechnical reference
                    townlight-planning 0.4.0.dev2AGPL-3.0-onlyBeta evaluation · Windows fresh-install scope
                    For Planning staff, municipal policy reviewers and authorized administrators

                    What the workflow delivers

                    1. Import adopted policy. Open Policy library. Preview jurisdiction, adoption/source dates, policy IDs, neighborhood applicability and originals, then confirm the complete source bundle. Retain the previous revision.
                    2. Create or reopen an analysis. Open Analyses and select the project. Use Next page when the loaded page does not contain the saved work. Enter the proposal, analysis and private staff notes.
                    3. Select policies and evidence. In Policies & evidence select exact policy revisions and applicable neighborhood context. Record supporting, conflicting or uncertain considerations. Select permitted Meetings or Zoning evidence with its expected hash.
                    4. Save and reconcile. Use Save draft before navigating or signing out. When another revision exists, reopen it and reconcile your edits. Do not resubmit against a guessed revision identifier.

                    Connected evidence

                    Selects Meetings and Zoning evidence. Provides permitted reviewed snapshots to Records. Source selection is permission- and hash-checked and is not automatic writeback.

                    Know the beta boundary

                    Existing initiative/amendment persistence is included. A draft amendment does not change an adopted source revision. Historical standalone sample pages are not the installed staff workspace. Analysis lists and project filters operate on loaded pages; use pagination to reach additional records.

                    Architecture

                    Where the evidence goes

                    Townlight Planning architecture and evidence flow

                    Selects Meetings and Zoning evidence. Provides permitted reviewed snapshots to Records. Source selection is permission- and hash-checked and is not automatic writeback.

                    Evidence rather than promises

                    Windows Sandbox acceptance passed.

                    The Windows acceptance summary describes the fresh Windows install, staff workflow, and 1.7.2.1 upgrade checks. See its scope for coverage of other workflows and equipment.

                    Read the exact acceptance and limits →

                    Ready to evaluate?

                    Begin with the current manual and download the Windows x64 beta 1.8.0.1. Configure the chosen test site and have its staff review source applicability and run the existing workflows.

                    Detailed READMEVersions and provenance
                    \ No newline at end of file +Townlight Planning | Townlight Beta 1
                    townlightTownlight Beta 1
                    Townlight Planning · Townlight Beta 1

                    Connect policy, analysis and municipal progress.

                    Planning retains adopted policy imports and neighborhood applicability, saved staff analyses, reviewed snapshots, municipal initiatives and amendment history. An analysis or amendment draft does not adopt policy.

                    Read the manualPrintable manualWord manualTechnical reference
                    townlight-planning 0.4.0.dev2AGPL-3.0-onlyBeta evaluation · Windows fresh install and tested 1.7.2.1 upgrade
                    For Planning staff, municipal policy reviewers and authorized administrators

                    What the workflow delivers

                    1. Import adopted policy. Open Policy library. Preview jurisdiction, adoption/source dates, policy IDs, neighborhood applicability and originals, then confirm the complete source bundle. Retain the previous revision.
                    2. Create or reopen an analysis. Open Analyses and select the project. Use Next page when the loaded page does not contain the saved work. Enter the proposal, analysis and private staff notes.
                    3. Select policies and evidence. In Policies & evidence select exact policy revisions and applicable neighborhood context. Record supporting, conflicting or uncertain considerations. Select permitted Meetings or Zoning evidence with its expected hash.
                    4. Save and reconcile. Use Save draft before navigating or signing out. When another revision exists, reopen it and reconcile your edits. Do not resubmit against a guessed revision identifier.

                    Connected evidence

                    Selects Meetings and Zoning evidence. Provides permitted reviewed snapshots to Records. Source selection is permission- and hash-checked and is not automatic writeback.

                    Know the beta boundary

                    Existing initiative/amendment persistence is included. A draft amendment does not change an adopted source revision. Historical standalone sample pages are not the installed staff workspace. Analysis lists and project filters operate on loaded pages; use pagination to reach additional records.

                    Architecture

                    Where the evidence goes

                    Townlight Planning architecture and evidence flow

                    Selects Meetings and Zoning evidence. Provides permitted reviewed snapshots to Records. Source selection is permission- and hash-checked and is not automatic writeback.

                    Evidence rather than promises

                    Windows Sandbox acceptance passed.

                    The Windows acceptance summary describes the fresh Windows install, staff workflow, and 1.7.2.1 upgrade checks. See its scope for coverage of other workflows and equipment.

                    Read the exact acceptance and limits →

                    Ready to evaluate?

                    Begin with the current manual and download the Windows x64 beta 1.8.0.1. Configure the chosen test site and have its staff review source applicability and run the existing workflows.

                    Detailed READMEVersions and provenance
                    \ No newline at end of file diff --git a/docs/beta-1/products/records/index.html b/docs/beta-1/products/records/index.html index 9b277e6..1099d80 100644 --- a/docs/beta-1/products/records/index.html +++ b/docs/beta-1/products/records/index.html @@ -1 +1 @@ -Townlight Records | Townlight Beta 1
                    townlightTownlight Beta 1
                    Townlight Records · Townlight Beta 1

                    From request intake to a deliberate release.

                    Records manages request intake, responsive evidence, review and the final response. Material received from another Townlight product is evidence for a request. Records separately controls release decisions, response approval, exports and fulfillment.

                    Read the manualPrintable manualWord manualTechnical reference
                    townlight-records 1.8.0.dev2AGPL-3.0-onlyBeta evaluation · Windows fresh-install scope
                    For Records officers, clerks and authorized reviewers

                    What the workflow delivers

                    1. Receive and identify the request. Create the request with its requester, description and recorded deadline basis. Save it and retain the request identifier. Record assignment, clarification and work in the request history.
                    2. Find responsive evidence. Search only the permitted sources. Inspect the source title, date, citation, visibility and version before attaching responsive material. Open the saved attachment to confirm that it is the intended evidence.
                    3. Preserve the original. Keep original bytes and their hash. Add a separately reviewed release-ready or redacted copy when needed. Renaming a private file does not remove private content.
                    4. Record each release decision. Explicitly record release, redact or exempt for the relevant document, with the applicable reason and source. Do not treat an AI suggestion or another product’s review as the Records legal decision.

                    Connected evidence

                    Receives selected evidence from Meetings, Code, Zoning, Planning, Permitting, Inspections and Station. Station originals are locked private evidence. A product’s public copy remains subject to the Records response workflow.

                    Know the beta boundary

                    The selected staff workflow is accepted. A resident internet deployment, every jurisdiction’s requirements, complete federation and exhaustive redaction/accessibility behavior are not certified by that acceptance. SMTP code exists; logging a message or outbox entry does not establish email delivery.

                    Architecture

                    Where the evidence goes

                    Townlight Records architecture and evidence flow

                    Receives selected evidence from Meetings, Code, Zoning, Planning, Permitting, Inspections and Station. Station originals are locked private evidence. A product’s public copy remains subject to the Records response workflow.

                    Evidence rather than promises

                    Windows Sandbox acceptance passed.

                    The Windows acceptance summary describes the fresh Windows install, staff workflow, and 1.7.2.1 upgrade checks. See its scope for coverage of other workflows and equipment.

                    Read the exact acceptance and limits →

                    Ready to evaluate?

                    Begin with the current manual and download the Windows x64 beta 1.8.0.1. Configure the chosen test site and have its staff review source applicability and run the existing workflows.

                    Detailed READMEVersions and provenance

                    The resident portal is deployed separately. See the Townlight Portal Guide for its workflow and acceptance limits.

                    \ No newline at end of file +Townlight Records | Townlight Beta 1
                    townlightTownlight Beta 1
                    Townlight Records · Townlight Beta 1

                    From request intake to a deliberate release.

                    Records manages request intake, responsive evidence, review and the final response. Material received from another Townlight product is evidence for a request. Records separately controls release decisions, response approval, exports and fulfillment.

                    Read the manualPrintable manualWord manualTechnical reference
                    townlight-records 1.8.0.dev2AGPL-3.0-onlyBeta evaluation · Windows fresh install and tested 1.7.2.1 upgrade
                    For Records officers, clerks and authorized reviewers

                    What the workflow delivers

                    1. Receive and identify the request. Create the request with its requester, description and recorded deadline basis. Save it and retain the request identifier. Record assignment, clarification and work in the request history.
                    2. Find responsive evidence. Search only the permitted sources. Inspect the source title, date, citation, visibility and version before attaching responsive material. Open the saved attachment to confirm that it is the intended evidence.
                    3. Preserve the original. Keep original bytes and their hash. Add a separately reviewed release-ready or redacted copy when needed. Renaming a private file does not remove private content.
                    4. Record each release decision. Explicitly record release, redact or exempt for the relevant document, with the applicable reason and source. Do not treat an AI suggestion or another product’s review as the Records legal decision.

                    Connected evidence

                    Receives selected evidence from Meetings, Code, Zoning, Planning, Permitting, Inspections and Station. Station originals are locked private evidence. A product’s public copy remains subject to the Records response workflow.

                    Know the beta boundary

                    The selected staff workflow is accepted. A resident internet deployment, every jurisdiction’s requirements, complete federation and exhaustive redaction/accessibility behavior are not certified by that acceptance. SMTP code exists; logging a message or outbox entry does not establish email delivery.

                    Architecture

                    Where the evidence goes

                    Townlight Records architecture and evidence flow

                    Receives selected evidence from Meetings, Code, Zoning, Planning, Permitting, Inspections and Station. Station originals are locked private evidence. A product’s public copy remains subject to the Records response workflow.

                    Evidence rather than promises

                    Windows Sandbox acceptance passed.

                    The Windows acceptance summary describes the fresh Windows install, staff workflow, and 1.7.2.1 upgrade checks. See its scope for coverage of other workflows and equipment.

                    Read the exact acceptance and limits →

                    Ready to evaluate?

                    Begin with the current manual and download the Windows x64 beta 1.8.0.1. Configure the chosen test site and have its staff review source applicability and run the existing workflows.

                    Detailed READMEVersions and provenance

                    The resident portal is deployed separately. See the Townlight Portal Guide for its workflow and acceptance limits.

                    \ No newline at end of file diff --git a/docs/beta-1/products/station/index.html b/docs/beta-1/products/station/index.html index 6e66280..25719e4 100644 --- a/docs/beta-1/products/station/index.html +++ b/docs/beta-1/products/station/index.html @@ -1 +1 @@ -Townlight Station | Townlight Beta 1
                    townlightTownlight Beta 1
                    Townlight Station · Townlight Beta 1

                    Capture the meeting and preserve its evidence.

                    Record council and board meetings, retain their agenda context, and deliver verified recording evidence to Records. Operators control capture, playout and approval. CivicCast remains an independent product.

                    Read the manualPrintable manualWord manualTechnical reference
                    townlight-station 0.3.0AGPL-3.0-onlyBeta evaluation · Windows fresh-install scope
                    For Station operators, clerks, Records staff and deployment administrators

                    What the workflow delivers

                    1. Prepare meeting context. Create and save the actual meeting and agenda in Meetings. Assign each selected agenda item to that meeting. A recording request cannot substitute an editable meeting label for the canonical records.
                    2. Open the operator. Sign in as authorized staff. Use the configured local operator command with the explicit native profile root. It obtains a short-lived one-use browser ticket; the native proof is not placed in the URL.
                    3. Choose the input. Select the meeting, assigned agenda and administrator-configured live-source ID. For recorded-file work, place the source in the managed ingest directory and optionally supply an SRT sidecar. Callers cannot submit arbitrary pipelines or filesystem paths.
                    4. Capture and stop. Start capture and distinguish waiting for a signal from active recording. Stop requests pipeline drain. Wait for completed status and validated output; a partial, failed or interrupted attempt is not a completed recording.

                    Connected evidence

                    Meetings → Station → Records is the accepted recording workflow. Townlight owns current session authority; Station owns its database, storage and media children. Standalone CivicCast remains separate, with no shared configuration, service, data directory or automatic updater fallback.

                    Know the beta boundary

                    There is no Station first-run wizard or automatic activation by the desktop composition. The accepted normal-profile path uses an explicitly configured paired Townlight HTTP process. Physical encoder/network, remote identity, SCM commissioning, CDN delivery and long-duration field quality are not certified. Station does not perform automatic meeting speech recognition.

                    Architecture

                    Where the evidence goes

                    Townlight Station architecture and evidence flow

                    Meetings → Station → Records is the accepted recording workflow. Townlight owns current session authority; Station owns its database, storage and media children. Standalone CivicCast remains separate, with no shared configuration, service, data directory or automatic updater fallback.

                    Evidence rather than promises

                    Windows Sandbox acceptance passed.

                    The Windows acceptance summary describes the fresh Windows install, staff workflow, and 1.7.2.1 upgrade checks. See its scope for coverage of other workflows and equipment.

                    Read the exact acceptance and limits →

                    Ready to evaluate?

                    Begin with the current manual and download the Windows x64 beta 1.8.0.1. Configure the chosen test site and have its staff review source applicability and run the existing workflows.

                    Detailed READMEVersions and provenance
                    Station delivery update

                    Live cable coverage and recorded video delivery

                    Station offers an encrypted live SRT feed to separate CivicCast while recording. The PEG operator controls cable broadcast. Completed recordings can be explicitly uploaded to YouTube with a reviewed title and chosen visibility. The private Records original stays intact.

                    Setup, staff steps and API examples

                    The resident portal is deployed separately. See the Townlight Portal Guide for its workflow and acceptance limits.

                    \ No newline at end of file +Townlight Station | Townlight Beta 1
                    townlightTownlight Beta 1
                    Townlight Station · Townlight Beta 1

                    Capture the meeting and preserve its evidence.

                    Record council and board meetings, retain their agenda context, and deliver verified recording evidence to Records. Operators control capture, playout and approval. CivicCast remains an independent product.

                    Read the manualPrintable manualWord manualTechnical reference
                    townlight-station 0.3.0AGPL-3.0-onlyBeta evaluation · Windows fresh install and tested 1.7.2.1 upgrade
                    For Station operators, clerks, Records staff and deployment administrators

                    What the workflow delivers

                    1. Prepare meeting context. Create and save the actual meeting and agenda in Meetings. Assign each selected agenda item to that meeting. A recording request cannot substitute an editable meeting label for the canonical records.
                    2. Open the operator. Sign in as authorized staff. Use the configured local operator command with the explicit native profile root. It obtains a short-lived one-use browser ticket; the native proof is not placed in the URL.
                    3. Choose the input. Select the meeting, assigned agenda and administrator-configured live-source ID. For recorded-file work, place the source in the managed ingest directory and optionally supply an SRT sidecar. Callers cannot submit arbitrary pipelines or filesystem paths.
                    4. Capture and stop. Start capture and distinguish waiting for a signal from active recording. Stop requests pipeline drain. Wait for completed status and validated output; a partial, failed or interrupted attempt is not a completed recording.

                    Connected evidence

                    Meetings → Station → Records is the accepted recording workflow. Townlight owns current session authority; Station owns its database, storage and media children. Standalone CivicCast remains separate, with no shared configuration, service, data directory or automatic updater fallback.

                    Know the beta boundary

                    There is no Station first-run wizard or automatic activation by the desktop composition. The accepted normal-profile path uses an explicitly configured paired Townlight HTTP process. Physical encoder/network, remote identity, SCM commissioning, CDN delivery and long-duration field quality are not certified. Station does not perform automatic meeting speech recognition.

                    Architecture

                    Where the evidence goes

                    Townlight Station architecture and evidence flow

                    Meetings → Station → Records is the accepted recording workflow. Townlight owns current session authority; Station owns its database, storage and media children. Standalone CivicCast remains separate, with no shared configuration, service, data directory or automatic updater fallback.

                    Evidence rather than promises

                    Windows Sandbox acceptance passed.

                    The Windows acceptance summary describes the fresh Windows install, staff workflow, and 1.7.2.1 upgrade checks. See its scope for coverage of other workflows and equipment.

                    Read the exact acceptance and limits →

                    Ready to evaluate?

                    Begin with the current manual and download the Windows x64 beta 1.8.0.1. Configure the chosen test site and have its staff review source applicability and run the existing workflows.

                    Detailed READMEVersions and provenance
                    Station delivery update

                    Live cable coverage and recorded video delivery

                    Station offers an encrypted live SRT feed to separate CivicCast while recording. The PEG operator controls cable broadcast. Completed recordings can be explicitly uploaded to YouTube with a reviewed title and chosen visibility. The private Records original stays intact.

                    Setup, staff steps and API examples

                    The resident portal is deployed separately. See the Townlight Portal Guide for its workflow and acceptance limits.

                    \ No newline at end of file diff --git a/docs/beta-1/products/zoning/index.html b/docs/beta-1/products/zoning/index.html index df664e9..be2f1ee 100644 --- a/docs/beta-1/products/zoning/index.html +++ b/docs/beta-1/products/zoning/index.html @@ -1 +1 @@ -Townlight Zoning | Townlight Beta 1
                    townlightTownlight Beta 1
                    Townlight Zoning · Townlight Beta 1

                    Bring parcel context and cited rules into one review.

                    Zoning combines local parcel geometry, cited zoning rules and staff review. It retains questions, corrections and snapshots with provenance so downstream staff can identify the precise evidence used.

                    Read the manualPrintable manualWord manualTechnical reference
                    townlight-zoning 0.2.3AGPL-3.0-onlyBeta evaluation · Windows fresh-install scope
                    For Planners, land-use staff and authorized reviewers

                    What the workflow delivers

                    1. Prepare parcel data. Use the complete supported bundle, including jurisdiction, dataset metadata and original hashes. The coordinates must be EPSG:4326. A loose geometry file is not the full source envelope.
                    2. Import and inspect. Check the complete source envelope before selecting Import parcel dataset. That control submits directly; inspect the saved validation/provenance result afterward. Correct a refused source bundle and preserve the evidence. Do not force acceptance by editing SQL.
                    3. Register cited rules. Associate the zone, rule kind/key and value with the relevant public Code section. Inspect overlays and effective context. Leave missing authority visible for planner review.
                    4. Ask a parcel question. Look up the intended parcel and ask the supported question. Read the returned citation, applicability and disclaimer. Do not present an uncertain answer as an official decision.

                    Connected evidence

                    Consumes Code authority and permitted Meetings evidence. Supplies permitted snapshots to Records and context to Planning and Permitting.

                    Know the beta boundary

                    The accepted path is local GeoJSON/PostGIS. It does not establish every ArcGIS, assessor or CKAN connector. Answers and process explanations are informational and do not issue an entitlement or an official zoning determination.

                    Architecture

                    Where the evidence goes

                    Townlight Zoning architecture and evidence flow

                    Consumes Code authority and permitted Meetings evidence. Supplies permitted snapshots to Records and context to Planning and Permitting.

                    Evidence rather than promises

                    Windows Sandbox acceptance passed.

                    The Windows acceptance summary describes the fresh Windows install, staff workflow, and 1.7.2.1 upgrade checks. See its scope for coverage of other workflows and equipment.

                    Read the exact acceptance and limits →

                    Ready to evaluate?

                    Begin with the current manual and download the Windows x64 beta 1.8.0.1. Configure the chosen test site and have its staff review source applicability and run the existing workflows.

                    Detailed READMEVersions and provenance
                    \ No newline at end of file +Townlight Zoning | Townlight Beta 1
                    townlightTownlight Beta 1
                    Townlight Zoning · Townlight Beta 1

                    Bring parcel context and cited rules into one review.

                    Zoning combines local parcel geometry, cited zoning rules and staff review. It retains questions, corrections and snapshots with provenance so downstream staff can identify the precise evidence used.

                    Read the manualPrintable manualWord manualTechnical reference
                    townlight-zoning 0.2.3AGPL-3.0-onlyBeta evaluation · Windows fresh install and tested 1.7.2.1 upgrade
                    For Planners, land-use staff and authorized reviewers

                    What the workflow delivers

                    1. Prepare parcel data. Use the complete supported bundle, including jurisdiction, dataset metadata and original hashes. The coordinates must be EPSG:4326. A loose geometry file is not the full source envelope.
                    2. Import and inspect. Check the complete source envelope before selecting Import parcel dataset. That control submits directly; inspect the saved validation/provenance result afterward. Correct a refused source bundle and preserve the evidence. Do not force acceptance by editing SQL.
                    3. Register cited rules. Associate the zone, rule kind/key and value with the relevant public Code section. Inspect overlays and effective context. Leave missing authority visible for planner review.
                    4. Ask a parcel question. Look up the intended parcel and ask the supported question. Read the returned citation, applicability and disclaimer. Do not present an uncertain answer as an official decision.

                    Connected evidence

                    Consumes Code authority and permitted Meetings evidence. Supplies permitted snapshots to Records and context to Planning and Permitting.

                    Know the beta boundary

                    The accepted path is local GeoJSON/PostGIS. It does not establish every ArcGIS, assessor or CKAN connector. Answers and process explanations are informational and do not issue an entitlement or an official zoning determination.

                    Architecture

                    Where the evidence goes

                    Townlight Zoning architecture and evidence flow

                    Consumes Code authority and permitted Meetings evidence. Supplies permitted snapshots to Records and context to Planning and Permitting.

                    Evidence rather than promises

                    Windows Sandbox acceptance passed.

                    The Windows acceptance summary describes the fresh Windows install, staff workflow, and 1.7.2.1 upgrade checks. See its scope for coverage of other workflows and equipment.

                    Read the exact acceptance and limits →

                    Ready to evaluate?

                    Begin with the current manual and download the Windows x64 beta 1.8.0.1. Configure the chosen test site and have its staff review source applicability and run the existing workflows.

                    Detailed READMEVersions and provenance
                    \ No newline at end of file diff --git a/docs/beta-1/terms.html b/docs/beta-1/terms.html index e045d75..d7d13ad 100644 --- a/docs/beta-1/terms.html +++ b/docs/beta-1/terms.html @@ -1,13 +1,13 @@ Terms of Service and License | Townlight Beta 1
                    townlightTownlight Beta 1
                    +header .brand{display:inline-flex;align-items:center;max-width:100%;flex-shrink:0}header .brand img{display:block;width:217px;max-width:100%;height:auto}
                    TownlightTownlight Beta 1
                    Townlight Beta 1

                    Terms of Service and License

                    Staff guide and technical reference

                    Public Windows beta 1.8.0.1
                    Windows x64 beta 1.8.0.1

                    +text.

                    \ No newline at end of file diff --git a/docs/index.html b/docs/index.html index 94504b6..4b12b84 100644 --- a/docs/index.html +++ b/docs/index.html @@ -1 +1 @@ -Townlight Zoning | Townlight Beta 1
                    townlightTownlight Beta 1
                    Townlight Zoning · Townlight Beta 1

                    Bring parcel context and cited rules into one review.

                    Zoning combines local parcel geometry, cited zoning rules and staff review. It retains questions, corrections and snapshots with provenance so downstream staff can identify the precise evidence used.

                    Read the manualPrintable manualWord manualTechnical reference
                    townlight-zoning 0.2.3AGPL-3.0-onlyBeta evaluation · Windows fresh-install scope
                    For Planners, land-use staff and authorized reviewers

                    What the workflow delivers

                    1. Prepare parcel data. Use the complete supported bundle, including jurisdiction, dataset metadata and original hashes. The coordinates must be EPSG:4326. A loose geometry file is not the full source envelope.
                    2. Import and inspect. Check the complete source envelope before selecting Import parcel dataset. That control submits directly; inspect the saved validation/provenance result afterward. Correct a refused source bundle and preserve the evidence. Do not force acceptance by editing SQL.
                    3. Register cited rules. Associate the zone, rule kind/key and value with the relevant public Code section. Inspect overlays and effective context. Leave missing authority visible for planner review.
                    4. Ask a parcel question. Look up the intended parcel and ask the supported question. Read the returned citation, applicability and disclaimer. Do not present an uncertain answer as an official decision.

                    Connected evidence

                    Consumes Code authority and permitted Meetings evidence. Supplies permitted snapshots to Records and context to Planning and Permitting.

                    Know the beta boundary

                    The accepted path is local GeoJSON/PostGIS. It does not establish every ArcGIS, assessor or CKAN connector. Answers and process explanations are informational and do not issue an entitlement or an official zoning determination.

                    Architecture

                    Where the evidence goes

                    Townlight Zoning architecture and evidence flow

                    Consumes Code authority and permitted Meetings evidence. Supplies permitted snapshots to Records and context to Planning and Permitting.

                    Evidence rather than promises

                    Windows Sandbox acceptance passed.

                    The Windows acceptance summary describes the fresh Windows install, staff workflow, and 1.7.2.1 upgrade checks. See its scope for coverage of other workflows and equipment.

                    Read the exact acceptance and limits →

                    Ready to evaluate?

                    Begin with the current manual and download the Windows x64 beta 1.8.0.1. Configure the chosen test site and have its staff review source applicability and run the existing workflows.

                    Detailed READMEVersions and provenance
                    +Townlight Zoning | Townlight Beta 1
                    townlightTownlight Beta 1
                    Townlight Zoning · Townlight Beta 1

                    Bring parcel context and cited rules into one review.

                    Zoning combines local parcel geometry, cited zoning rules and staff review. It retains questions, corrections and snapshots with provenance so downstream staff can identify the precise evidence used.

                    Read the manualPrintable manualWord manualTechnical reference
                    townlight-zoning 0.2.3AGPL-3.0-onlyBeta evaluation · Windows fresh install and tested 1.7.2.1 upgrade
                    For Planners, land-use staff and authorized reviewers

                    What the workflow delivers

                    1. Prepare parcel data. Use the complete supported bundle, including jurisdiction, dataset metadata and original hashes. The coordinates must be EPSG:4326. A loose geometry file is not the full source envelope.
                    2. Import and inspect. Check the complete source envelope before selecting Import parcel dataset. That control submits directly; inspect the saved validation/provenance result afterward. Correct a refused source bundle and preserve the evidence. Do not force acceptance by editing SQL.
                    3. Register cited rules. Associate the zone, rule kind/key and value with the relevant public Code section. Inspect overlays and effective context. Leave missing authority visible for planner review.
                    4. Ask a parcel question. Look up the intended parcel and ask the supported question. Read the returned citation, applicability and disclaimer. Do not present an uncertain answer as an official decision.

                    Connected evidence

                    Consumes Code authority and permitted Meetings evidence. Supplies permitted snapshots to Records and context to Planning and Permitting.

                    Know the beta boundary

                    The accepted path is local GeoJSON/PostGIS. It does not establish every ArcGIS, assessor or CKAN connector. Answers and process explanations are informational and do not issue an entitlement or an official zoning determination.

                    Architecture

                    Where the evidence goes

                    Townlight Zoning architecture and evidence flow

                    Consumes Code authority and permitted Meetings evidence. Supplies permitted snapshots to Records and context to Planning and Permitting.

                    Evidence rather than promises

                    Windows Sandbox acceptance passed.

                    The Windows acceptance summary describes the fresh Windows install, staff workflow, and 1.7.2.1 upgrade checks. See its scope for coverage of other workflows and equipment.

                    Read the exact acceptance and limits →

                    Ready to evaluate?

                    Begin with the current manual and download the Windows x64 beta 1.8.0.1. Configure the chosen test site and have its staff review source applicability and run the existing workflows.

                    Detailed READMEVersions and provenance