segregated witness – Creating a raw Segwit transaction from scratch and getting Signature must be zero for failed CHECK(MULTI)SIG operation

I am trying to create a Segwit transaction on TESTNET from scratch while referencing an online guide:
https://medium.com/coinmonks/creating-and-signing-a-segwit-transaction-from-scratch-ec98577b526a

My BIP-39 mnemonics code:

differ toast alert candy orbit raccoon wagon hour thunder kiwi home cigar

My TESTNET BIP-32 master public key derived Segwit Bech32 address with derivation path ‘m’:

tb1qzjgctgz9t98dmkwp4z26whg6tl4w9s6rl6hwwj

The address profile can be viewed from here.

Just for simplicity of debugging, the derivation ‘m’ will be used only.

For more context the Master Public Key compressed format:

03D7DE86033E1C815BA0E3589938B7AC906B728F1F2C771542E203E32B80A3385A

For more context the Master Public Key uncompressed format:

04D7DE86033E1C815BA0E3589938B7AC906B728F1F2C771542E203E32B80A3385AE1DEED79187355D35FDABAF74DFD186A8B8C9FE1D6357AA46750A47B86ED16CF

The raw BIP-32 Seed:

1CD4561EF82D35F9EE2E95ED63B68BB91ADA8967E1D98FA4080637A4CC310BE99DD285F82F45EE004ADC408F8B93C2A829A5B811104496A6FB0301E062CBC813

The raw Master Private Key used for the digital signing later:

13D84CAC526896CEF2594D71621D2AEDC90F9DAEA88A1751AD99E35868E0021B

I would like to send myself (tb1qzjgctgz9t98dmkwp4z26whg6tl4w9s6rl6hwwj) some funds (0x5503000000000000 / 853 satoshis) using my own address (tb1qzjgctgz9t98dmkwp4z26whg6tl4w9s6rl6hwwj).

So, I begin to create the Segwit inputs that would then be double-SHA256 hashed then signed.

It follows the BIP143 defined steps:

Double SHA256 of the serialization of:
 1.  nVersion of the transaction (4-byte little endian)
 2.  hashPrevouts (32-byte hash)
 3.  hashSequence (32-byte hash)
 4.  outpoint (32-byte hash + 4-byte little endian) 
 5.  scriptCode of the input (serialized as scripts inside CTxOuts)
 6.  value of the output spent by this input (8-byte little endian)
 7.  nSequence of the input (4-byte little endian)
 8.  hashOutputs (32-byte hash)
 9.  nLocktime of the transaction (4-byte little endian)
 10. sighash type of the signature (4-byte little endian)

// 1.  nVersion of the transaction (4-byte little endian)
<<< 01000000

// 2.  hashPrevouts (32-byte hash)
>>> printf "4E2F5CCED0DC6D7B229AB43381A7DDBAB759C457C3366D8435782120493133A0 00000000" | xxd -p -r | sha256sum -b | xxd -p -r | sha256sum -b

<<< 04dc164c0a705f5d2d57fd42e6896a94394e6966ed0b116a64adfaa9310b848f

//  3.  hashSequence (32-byte hash)

>>> printf "ffffffff" | xxd -p -r | sha256sum | xxd -p -r | sha256sum

<<< 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044

//  4.  outpoint (32-byte hash + 4-byte little endian) 

<<< 4E2F5CCED0DC6D7B229AB43381A7DDBAB759C457C3366D8435782120493133A0 00000000

//  5.  scriptCode of the input (serialized as scripts inside CTxOuts)

<<< 1976a914149185A045594EDDD9C1A895A75D1A5FEAE2C34388ac

//  6.  value of the output spent by this input (8-byte little endian)

<<< e803000000000000

//  7.  nSequence of the input (4-byte little endian)

<<< ffffffff

// 8.  hashOutputs (32-byte hash)
          
>>> printf "e803000000000000 16 0014149185A045594EDDD9C1A895A75D1A5FEAE2C343" | xxd -p -r | sha256sum -b | xxd -p -r | sha256sum -b

<<< 7c007a193409e64199438db0ba4349809fbcc42c17e7167cbc06deec4cc0998f

// 9.  nLocktime of the transaction (4-byte little endian)
<<< 00000000

// 10. sighash type of the signature (4-byte little endian)
<<< 01000000

// Hashing with double Sha256

>>> printf 0100000004dc164c0a705f5d2d57fd42e6896a94394e6966ed0b116a64adfaa9310b848f3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e706650444E2F5CCED0DC6D7B229AB43381A7DDBAB759C457C3366D8435782120493133A0000000001976a914149185A045594EDDD9C1A895A75D1A5FEAE2C34388ace803000000000000ffffffff7c007a193409e64199438db0ba4349809fbcc42c17e7167cbc06deec4cc0998f0000000001000000 | xxd -p -r | sha256sum -b | xxd -p -r | sha256sum -b

<<< c2636fae9487354f47e4e92458a7e856f717533c6d01e1c5fda5b06c4a1976a8

The encoded digital signature result:

30450221008B61503427B2292F781405712DF878B207D8B89FC86D60B1A68D479CA6C6FF2302203BB1F7F5F7E2B9050BA481310C997F6F078F5ED25564AEC85277EB56BA98FD76

Finally, formatted into a raw transaction below:

010000000001014E2F5CCED0DC6D7B229AB43381A7DDBAB759C457C3366D8435782120493133A00000000000FFFFFFFF015503000000000000160014149185A045594EDDD9C1A895A75D1A5FEAE2C343024830450221008B61503427B2292F781405712DF878B207D8B89FC86D60B1A68D479CA6C6FF2302203BB1F7F5F7E2B9050BA481310C997F6F078F5ED25564AEC85277EB56BA98FD76012103D7DE86033E1C815BA0E3589938B7AC906B728F1F2C771542E203E32B80A3385A00000000

The broadcast results throws the following error:

sendrawtransaction RPC error: {"code":-26,"message":"non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation)"}

I have checked the digital signatures many times and ran validation on the signatures and public key with assumption that all the above addresses and scripts are valid.

How do I fix the failed broadcast ? What are the causes of the failed broadcast ?