doc(development guide): Add information about form fields in dev guide

development-guide.md

@@ -13,7 +13,7 @@ Fivetran SDK uses [gRPC](https://grpc.io/) to talk to partner code. The partner
 At the moment, partner code should be developed in a language that can generate a statically linked binary executable.
 
 ### Command line Arguments
-The executable needs to do following:
+The executable needs to do the following:
 * Accept a `--port` argument that takes an integer as a port number to listen to.
 * Listen on both IPV4 (i.e. 0.0.0.0) and IPV6 (i.e ::0), but if only one is possible, it should listen on IPV4.
 
@@ -80,14 +80,37 @@ The following are hard requirements to be able to deploy partner code to Fivetra
 - Do not log sensitive data. Ensure only necessary information is kept in logs, and never log any sensitive data. Such data may include credentials (passwords, tokens, keys, etc.), customer data, payment information, or PII.
 - Encrypt HTTP requests. Entities like URLs, URL parameters, and query parameters are always encrypted for logging, and customer approval is needed to decrypt and examine them.
 
+## Setup Form Guidelines
+- Keep the form clear and concise, only requesting essential information for successful connector setup.
+- Use clear and descriptive labels for each form field. Avoid technical jargon if possible.
+- Organize the fields in a logical order that reflects the setup process.
 
-## Connector guidelines
+### RPC Calls
+#### ConfigurationForm
+The `ConfigurationForm` RPC call retrieves all the setup form fields and tests information. You can provide various parameters for the fields to enhance the user experience, such as descriptions, optional fields, and more.
+
+#### Test
+The [`ConfigurationForm` RPC call](#configurationform) retrieves the tests that need to be executed during connection setup. The `Test` call then invokes the test with the customer's credentials as parameters. As a result, it should return a success or failure indication for the test execution.
+
+### Supported setup form fields 
+- Text Field: A standard text input field for user text entry. You can provide a `title` displayed above the field. You can indicate whether the field is `required`, and you may also include an optional `description` displayed below the field to help explain what the user should complete.
+- Dropdown: A drop-down menu that allows users to choose one option from the list you provided.
+- Toggle Field: A toggle switch for binary options (e.g., on/off or yes/no).
+
+## Source Connector guidelines
 
 - Don't push anything other than source data to the destination. State data is saved to production database and returned in `UpdateRequest`.
 - Don't forget to handle new schemas/tables/columns per the information and user choices in `UpdateRequest#selection`.
 - Make sure you checkpoint at least once an hour. In general, the more frequently you do it, the better.
 
-## Destination guidelines
+### RPC Calls
+#### Schema
+The `Schema` RPC call retrieves the user's schemas, tables, and columns. It also includes an optional `selection_not_supported` field that indicates whether the user can select or deselect tables and columns within the Fivetran dashboard.
+
+#### Update
+The `Update` RPC call should retrieve data from the source. We send a request using the `UpdateRequest` message, which includes the user's connection state, credentials, and schema information. The response, streaming through the `UpdateResponse` message, can contain data records and other supported operations.
+
+## Destination Connector guidelines
 
 - Do not push anything other than source data to the destination.
 
@@ -116,26 +139,32 @@ Batch files are compressed using [ZSTD](https://en.wikipedia.org/wiki/Zstd).
 
 ### RPC Calls
 #### CreateTable
-This operation should fail if it is asked to create a table that already exists. However, it should not fail if the target schema is missing. The destination should create the missing schema.
+The `CreateTable` RPC call should fail if it is asked to create a table that already exists. However, it should not fail if the target schema is missing. The destination should create the missing schema.
 
 #### DescribeTable
-This operation should report all columns in the destination table, including Fivetran system columns such as `_fivetran_synced` and `_fivetran_deleted`. It should also provide other additional information as applicable such as data type, `primary_key`, and `DecimalParams`.
+The `DescribeTable` RPC call should report all columns in the destination table, including Fivetran system columns such as `_fivetran_synced` and `_fivetran_deleted`. It should also provide other additional information as applicable such as data type, `primary_key`, and `DecimalParams`.
 
 #### Truncate
-- This operation might be requested for a table that does not exist in the destination. In that case, it should NOT fail, simply ignore the request and return `success = true`.
+- The `Truncate` RPC call might be requested for a table that does not exist in the destination. In that case, it should NOT fail, simply ignore the request and return `success = true`.
 - `utc_delete_before` has millisecond precision.
 
 #### AlterTable
-- This operation should be used for changing primary key columns, adding columns, and changing data types. 
+- The `AlterTable` RPC call should be used for changing primary key columns, adding columns, and changing data types. 
 - However, this operation should not drop any columns even if the `AlterTable` request has a table with a different set of columns. Dropping columns could lead to unexpected customer data loss and is against Fivetran's general approach to data movement.
 
 #### WriteBatchRequest
-- `replace_files` is for the `upsert` operation where the rows should be inserted if they don't exist or updated if they do. Each row always provides values for all columns. Populate the `_fivetran_synced` column in the destination with the values coming in from the CSV files.
+The `WriteBatchRequest` RPC call provides details about the batch files containing the records to be pushed to the destination. We provide the `WriteBatchRequest` parameter that contains all the information required for you to read the batch files. Here are some of the fields included in the request message:
+
+- `replace_files` is for the `upsert` operation where the rows should be inserted if they don't exist or updated if they do. Each row will always provide values for all columns. Set the `_fivetran_synced` column in the destination with the values coming in from the batch files.
 
-- `update_files` is for the `update` operation where modified columns have actual values whereas unmodified columns have the special value `unmodified_string` in `CsvFileParams`. Soft-deleted rows arrive in here as well. Update the `_fivetran_synced` column in the destination with the values coming in from the CSV files.
+- `update_files` is for the `update` operation where modified columns have actual values whereas unmodified columns have the special value `unmodified_string` in `FileParams`. Soft-deleted rows will arrive in here as well. Update the `_fivetran_synced` column in the destination with the values coming in from the batch files.
 
 - `delete_files` is for the `hard delete` operation. Use primary key columns (or `_fivetran_id` system column for primary-keyless tables) to perform `DELETE FROM`.
 
+- `keys` is a map that provides a list of secret keys, one for each batch file, that can be used to decrypt them.
+
+- `file_params` provides information about the file type and any configurations applied to it, such as encryption or compression.
+
 Also, Fivetran deduplicates operations such that each primary key shows up only once in any of the operations.
 
 Do not assume order of columns in the batch files. Always read the CSV file header to determine the column order.